LUNAROPS · OPERATIONAL UPLINK 100% UPTIME 1,247d POSTS 893 JEFF.MOON@LUNAROPS.DEV UTC --:--:--

Open-Source Licensing, Actually Explained

15 min read Law & Standards
open-sourcelicensinggplcopyleftcompliancelaw-and-standards
Contents

Almost every engineer ships other people’s code, and almost none of them have read the licenses that govern it. This works right up until it doesn’t: until a lawyer asks whether your product can be distributed, until an acquirer’s due-diligence team finds AGPL code in your closed-source backend, until the database you built a business on relicenses out from under you and you have to decide overnight whether to follow it, fork it, or rip it out. Open-source licensing is not a legal curiosity to delegate — it is a set of engineering constraints that determine what you are allowed to build, ship, and keep private, and the constraints are encoded in maybe a dozen licenses you can actually learn. The good news is that the landscape is far more comprehensible than its reputation suggests: there are two big ideas (permissive and copyleft), one wrinkle that the cloud era exposed (the SaaS loophole), and a recent wave of relicensing dramas that, once you understand the mechanics, all tell the same story. This post is the working engineer’s map — what each license actually obligates you to do, why the industry has been at war over licensing since 2018, and a checklist for not getting burned.

The foundation that confuses people is this: open-source licenses work because of copyright, not in opposition to it. By default, copyright law forbids copying, modifying, or distributing someone’s code at all. A license is a grant — the author saying “you may do these things, provided you meet these conditions.” Every obligation in an open-source license is a condition on that grant. Violate the condition and you lose the grant, which means you are now infringing copyright, which is the actual enforcement mechanism. There is no “open-source police”; there is only the copyright holder’s ability to sue you for infringement once you have stepped outside the permission they gave.

This framing makes everything else legible. “Copyleft” is not magic — it is a copyright holder conditioning your right to distribute on your agreeing to distribute your changes under the same terms. The license is enforceable for exactly the same reason any copyright is. It is the mirror image of the patent system covered in the software patents guide: patents grant a right to exclude others from an invention, while copyright licenses grant a conditional right to use an expression. Both are intellectual-property levers; open source pulls the copyright one in an unusual direction.

The Open Source Initiative (OSI) maintains the canonical definition of what counts as “open source,” and the key clauses for our purposes are that the license must permit redistribution, allow modifications and derived works, and not discriminate against fields of use (you cannot say “free for everyone except cloud providers”). That last clause is the entire battlefield of the relicensing wars, and we will return to it.

The Two Families: Permissive and Copyleft

Strip away the dozens of license names and there are two philosophies, distinguished by a single question: when you take this code and build on it, what must you give back?

Permissive licenses (MIT, BSD, Apache 2.0) answer: almost nothing. Use the code however you like — in proprietary products, in closed-source services, modified or not — and your only real obligation is attribution (keep the copyright notice and license text). You can take MIT-licensed code, modify it, and ship it inside a closed binary you sell, and you owe the author nothing but credit. Apache 2.0 adds one thing worth knowing: an explicit patent grant, where contributors license any patents their contribution practices, with a termination clause if you sue over patents. This is why Apache 2.0 is the corporate-preferred permissive license — it manages patent risk that MIT and BSD leave silent.

Copyleft licenses (the GPL family) answer: you must give back your changes, under the same license. This is the “viral” or “reciprocal” property. If you distribute software that incorporates GPL code, you must release the complete corresponding source of the whole derived work under the GPL, including your modifications. The intent is to keep the software and all its descendants free. Copyleft comes in strengths:

License Family What you must share Trigger Typical use
MIT / BSD Permissive Nothing but attribution None Libraries meant for max adoption
Apache 2.0 Permissive Attribution + patent terms None Corporate-friendly libraries
LGPL Weak copyleft Changes to the library itself Distribution Libraries linked by proprietary apps
MPL 2.0 Weak copyleft (file-level) Changes to MPL-licensed files Distribution Per-file reciprocity (Firefox, old Terraform)
GPLv2 / GPLv3 Strong copyleft Entire derived work’s source Distribution Whole applications (Linux is GPLv2)
AGPLv3 Network copyleft Entire derived work’s source Distribution OR network use Server software wanting SaaS reciprocity

The crucial subtlety in strong copyleft is the trigger: standard GPL obligations fire on distribution. If you modify GPL software and run it only on your own servers, never giving anyone a copy of the binary, you have distributed nothing and owe nothing — you can keep your changes private indefinitely. This “internal use” freedom is enormous and entirely legal, and it is exactly the gap the cloud era drove a truck through.

The Linking Question and the SaaS Loophole

Two practical questions dominate copyleft in real codebases, and both are murkier than the license text admits.

The first is linking: if my proprietary program links against a GPL library, is my program now a derived work that must be GPL’d? The Free Software Foundation’s position is yes — dynamic or static linking creates a single combined work, so linking GPL code into proprietary software triggers copyleft on the whole thing. This is precisely why the LGPL exists: it weakens copyleft so that a proprietary application can link an LGPL library while keeping the application itself proprietary, requiring only that modifications to the library be shared and that users can swap in their own version. The legal force of the FSF’s linking position has never been fully tested in court, which is why cautious legal teams treat it as true regardless — the risk of being the test case is not worth it. The practical rule most companies adopt: GPL libraries are fine for internal tools and GPL products, dangerous inside proprietary distributed software, and LGPL is the safer dependency if you must link from closed source.

The second is the SaaS loophole, and it reshaped the industry. The GPL’s distribution trigger was written in an era when “using software” meant running a binary on your own machine. But if you take GPL server software, modify it, and run it as a cloud service that users interact with over a network, your users never receive a copy — there is no distribution — so the copyleft never triggers. You get all the benefit of the modifications while keeping them private. The FSF closed this gap with the AGPLv3, which adds a network trigger: if users interact with modified AGPL software over a network, you must offer them the source. AGPL treats “providing access as a service” as equivalent to distribution.

   GPL trigger model (pre-cloud):

   modify GPL code ---> ship binary to user ---> MUST share source
   modify GPL code ---> run only on your server --> share NOTHING (loophole)

   AGPL closes it:

   modify AGPL code --> run as a network service --> MUST offer source
                        (even with no binary handed out)

The AGPL is the most consequential license in the modern wars, because it is the strongest OSI-approved tool a company has to force cloud providers who offer their software as a managed service to either contribute back or stay away. Hold that thought — it is the resolution to most of the dramas below.

The Relicensing Wars: Same Plot, Many Casts

Since roughly 2018, a recurring drama has played out: an open-source company watches a hyperscaler (usually AWS) sell its software as a managed service, capturing revenue the company feels it should earn, and responds by abandoning its open-source license for something more restrictive. The community forks the last open version. Sometimes the company retreats. The cast changes; the plot does not.

MongoDB (2018) fired the first major shot, moving from AGPL to the Server Side Public License (SSPL). The SSPL’s innovation was a poison pill aimed squarely at cloud providers: if you offer SSPL software as a service, you must open-source not just your changes but your entire service stack — the management, monitoring, and orchestration code around it. This was so broad that the OSI refused to recognize the SSPL as open source at all, because it discriminates against a field of use (offering a service). MongoDB became “source-available,” not open source.

Elastic (2021) followed, relicensing Elasticsearch and Kibana from Apache 2.0 to a dual SSPL/Elastic License model after years of friction with AWS. AWS responded by forking the last Apache-licensed version into OpenSearch, which it later donated to the Linux Foundation. Three years later, in a notable reversal, Elastic added AGPLv3 as an option in 2024 — returning to genuinely OSI-approved open source. The CTO’s framing was that the landscape had changed and the AWS relationship had normalized; the cynical read is that OpenSearch had gained enough traction that source-available was costing more than it protected.

HashiCorp (2023) moved Terraform, Vault, and its other tools from the Mozilla Public License to the Business Source License (BSL) 1.1 — a “source-available” license where the code is visible and usable, but a use-limitation clause forbids competing commercial offerings, and each version automatically converts to a true open-source license (here MPL) after four years. The Terraform community forked the last MPL version into OpenTofu, adopted by the Linux Foundation, and the resulting divergence is significant enough to warrant its own comparison (OpenTofu vs Terraform). IBM then acquired HashiCorp for $6.4 billion, closing in February 2025, with the licenses remaining BSL.

Redis (2024-2025) is the most instructive because it ran the full cycle in eighteen months. Redis moved from the permissive BSD license to dual SSPLv1/RSALv2 in March 2024, immediately triggering a fork — Valkey, BSD-licensed, hosted by the Linux Foundation, and backed within weeks by AWS, Google Cloud, and Oracle. Then, in a remarkable reversal, original creator Salvatore Sanfilippo rejoined Redis in late 2024, and in May 2025 Redis added AGPLv3 to Redis 8, returning to OSI-approved open source and folding the previously-proprietary Redis Stack modules into the open core. The lesson Redis learned in real time: a permissive-to-restrictive move can spawn a credible, well-funded fork fast, and AGPL was available the whole time as the open-source-preserving way to achieve most of what they wanted (the Redis beyond caching post covers the technology now split across both projects).

Company From To Year Fork response Later reversal
MongoDB AGPL SSPL 2018 (none major) No
Elastic Apache 2.0 SSPL + ELv2 2021 OpenSearch (AWS) Added AGPL, 2024
HashiCorp MPL 2.0 BSL 1.1 2023 OpenTofu No (acquired by IBM)
Redis BSD SSPL + RSAL 2024 Valkey (LF) Added AGPL, 2025

The pattern’s throughline: the restrictive moves are aimed at hyperscalers, the collateral damage lands on everyone else, and the fork — when backed by a cloud provider or a foundation — frequently wins enough mindshare that the original company’s restriction backfires. AGPL keeps reappearing as the answer that achieves the actual goal (forcing cloud reciprocity) while staying inside the open-source definition.

Source-Available Is Not Open Source

The wars produced a vocabulary trap worth being precise about. “Source-available” means you can read and often use the source, but the license fails the OSI definition — usually by restricting a field of use (no competing services) or commercial use. SSPL, BSL, the Elastic License, and the Redis RSAL are all source-available. They are not open source, regardless of how the marketing reads, and the distinction has real consequences:

  • You may not be able to use it the way you assume. A BSL use-limitation can forbid exactly the commercial offering you are building. Read the specific grant.
  • Foundations and distros will not ship it. Debian, Fedora, and the CNCF will not package non-OSI licenses, which is why the forks (OpenTofu, Valkey, OpenSearch) immediately become the version that ecosystems standardize on.
  • “Eventually open” is not “open now.” BSL’s four-year conversion means today’s version is proprietary for four years; you cannot treat it as open source in the present.

This is not a moral judgment — source-available is a legitimate business model, and “open core” (open-source core, proprietary enterprise features) funds much of the ecosystem. It is a precision requirement: know which bucket your dependency is in, because the buckets have different rules.

Contributing: CLAs vs. DCOs

If you contribute code upstream — or accept contributions to your project — one more mechanism matters, because it determines who can relicense later (and is precisely how the companies above were able to relicense).

A Developer Certificate of Origin (DCO) is a lightweight attestation: you add a Signed-off-by line to your commit certifying you have the right to contribute the code under the project’s license. You retain copyright; you grant only the license everyone else gets. The Linux kernel uses the DCO. It is low-friction and contributor-friendly.

A Contributor License Agreement (CLA) is heavier: you sign a separate legal agreement, often assigning copyright to the project steward or granting them a broad license including the right to relicense your contribution under different terms in the future. This is what lets a single company hold enough rights to relicense the whole codebase — every relicensing drama above was possible because the company had gathered sufficient rights (via CLA or sole authorship) to change the terms unilaterally.

1
2
3

# DCO: just sign your commit (retains your copyright)
git commit -s -m "Fix connection pool leak"
# adds: Signed-off-by: Your Name <you@example.com>

The practical reading for contributors: a CLA that grants relicensing rights is a signal that the steward can pull a HashiCorp on you later. That is not a reason to refuse — plenty of healthy projects use CLAs — but it is information. Community-governed projects under a foundation, with a DCO, structurally cannot be unilaterally relicensed, which is a large part of why the forks fled to foundations.

A Practical Compliance Checklist

For shipping a product that depends on open-source code, the discipline is mostly bookkeeping done continuously rather than heroically at the end:

  • Generate a Software Bill of Materials (SBOM) and scan licenses automatically in CI. Tools like syft, scancode, FOSSA, or license-checker enumerate every dependency’s license. Do this on every build, not once a year.
1
2
3

# Generate an SBOM and inspect the license distribution
syft dir:. -o spdx-json > sbom.json
syft dir:. -o table | awk '{print $NF}' | sort | uniq -c | sort -rn
  • Classify by distribution model. The same dependency carries different obligations depending on whether you ship a binary, ship a container, or run a service. AGPL is fine for an internal tool, a live grenade in a proprietary SaaS. GPL in a library you statically link into a closed binary is a problem; the same GPL in a build-time-only tool is not.
  • Maintain attribution. Permissive licenses require preserving copyright notices and license texts. Aggregate them into a THIRD_PARTY_LICENSES file shipped with your product. This is the single most common trivial violation.
  • Watch copyleft reciprocity. If you modify and distribute GPL/LGPL/MPL code, you owe source for the covered portions. Track which files you have touched.
  • Flag source-available dependencies explicitly. SSPL/BSL/ELv2 dependencies need a human legal read against your specific use, because their restrictions are use-case-dependent in a way OSI licenses are not.
  • Pin and monitor for relicensing. The wars proved that a dependency’s license can change under you. Pin versions, and watch upstream license files so a SSPL or BSL switch is a deliberate decision, not a surprise in your next go get.
  • Get a real legal review before shipping or fundraising. This checklist reduces risk; it does not replace counsel. An acquirer’s diligence team will run exactly these scans, and finding problems then is far more expensive than finding them now — the same forethought that separates a side project that ships from a liability.

Verdict

Open-source licensing is far more tractable than its reputation, and the payoff for learning it is direct: you stop shipping legal landmines and start making deliberate choices. Hold a few things and you have most of it. Copyleft works through copyright, so every obligation is a condition on a grant you can lose. Permissive licenses ask for attribution and little else; copyleft asks for your changes back, with strong copyleft triggering on distribution and AGPL extending that to network use — which is the whole reason the cloud era has been at licensing war since 2018. Source-available licenses like SSPL and BSL are a legitimate but distinct category that is not open source, will not be packaged by foundations, and needs a use-specific legal read. The relicensing dramas all rhyme: a company restricts to fight a hyperscaler, a foundation-backed fork answers, and AGPL keeps turning out to be the move that achieves the goal without leaving the open-source fold — which is why both Elastic and Redis eventually walked back to it. For your own products, treat license compliance as continuous bookkeeping: scan in CI, classify by how you distribute, preserve attribution, and pin against the next surprise relicense. None of this requires a law degree. It requires reading the license before you depend on it, which almost nobody does, which is exactly why knowing this is an edge.

Sources

Comments