This connects directly to one existing guide worth naming up front: our guide on software ownership covers what open-source license terms mean for a company consuming open-source code — the disclosure obligations that can attach to a product that depends on GPL or AGPL components. This guide covers the opposite decision: choosing to release part of your own commercial product as open or source-available software, and the real, documented history of companies that made — and later reversed — that choice.
Why Companies Open-Source Part of a Commercial Product
Why would a commercial company give away part of its product as open source?
Three real, commonly cited reasons: it builds an adoption funnel where developers try a free, open core before a company ever pays; it builds community trust and technical credibility, since engineers can audit the actual code rather than trusting marketing claims; and it functions as a distribution channel that a closed-source competitor cannot easily replicate, because installs and stars accumulate before any sales conversation happens.
GitLab is the most directly documented real example of a company stating this rationale in its own words. In a company blog post explicitly contrasting itself with a then-closed-source GitHub, GitLab described itself as “open core” — publishing its Community Edition (CE) under the MIT license while keeping additional enterprise-tier functionality in a proprietary Enterprise Edition (EE) (GitLab Blog, “GitLab is open core, GitHub is closed source,” July 20, 2016). The practical logic GitLab has described publicly: individual-contributor and core version-control functionality stays open, because that is what drives adoption and community trust, while collaboration-at-scale and enterprise-management features — the features an organization, not an individual developer, actually pays for — sit behind the paid tier.
A second, more defensive real motivation shows up in Confluent's licensing history. Confluent kept Apache Kafka itself under the Apache Software Foundation's Apache License 2.0 — Kafka is not Confluent's to relicense, since it is an ASF project — but moved select components of its own Confluent Platform to a proprietary Confluent Community License that explicitly forbids using the software to offer a competing hosted service (an “Excluded Purpose” covering software-as-a-service, platform-as-a-service, and infrastructure-as-a-service offerings). This is a real, documented example of open-sourcing (or, in this case, deliberately not fully open-sourcing) being used specifically to block a large cloud provider from re-hosting a company's own software as a competing managed service without contributing back (Confluent Community License FAQ).
A third, more recent real example shows a company moving in the opposite direction from a fully OSI-approved license toward a new, explicitly-named middle ground. Sentry announced on August 6, 2024 that it was adopting what it called “Fair Source” licensing — a model Sentry itself describes as source-available rather than OSI open source, explicitly trading full open-source purity for continued sustainability of its own development (Sentry Blog, “Sentry is now Fair Source,” August 6, 2024). Sentry's own public position, stated across its own blog posts on open-source values, is that it sees supporting a genuinely sustainable business as inseparable from being able to keep building the product at all — a framing that treats “fully open source forever” and “a company that survives to keep maintaining the product” as a real tension worth naming directly rather than assuming the two are always compatible.
The License Taxonomy: What Each One Actually Requires
What do MIT, Apache 2.0, GPL, AGPL, and source-available licenses actually require, in practice?
MIT and BSD impose no source-disclosure obligation at all. Apache 2.0 adds an explicit patent grant and patent-retaliation clause but still imposes no copyleft obligation. GPL requires that distributed derivative works also be licensed under GPL and have their source made available. AGPL closes the “SaaS loophole” in GPL by extending that same disclosure obligation to software offered only as a network service, never distributed at all. Source-available licenses like the Business Source License and the Server Side Public License are not OSI-approved open source licenses, because they restrict specific commercial or competitive uses.
The MIT License is the most permissive widely-used license: it permits use, copying, modification, merging, publishing, distribution, sublicensing, and sale of copies, with the sole requirement that the original copyright and permission notice be preserved in copies (Open Source Initiative, MIT License text). The Apache License 2.0 is similarly permissive but adds two real, meaningful provisions the MIT license lacks: an express patent grant from contributors, and a patent-retaliation clause that terminates that grant against anyone who sues over patent infringement claims related to the software (Apache Software Foundation, License, Version 2.0). Neither MIT nor Apache 2.0 requires releasing the source of a derivative or modified work — this is exactly what separates a “permissive” license from a “copyleft” one.
The GNU General Public License (GPL), published by the Free Software Foundation, is the canonical strong copyleft license: any distributed derivative or modified work must also be licensed under GPL, and its source must be made available to recipients (GNU General Public License v3.0). The GNU Affero General Public License (AGPL) v3 carries the identical copyleft obligation but closes a specific, real loophole GPL leaves open: GPL's disclosure obligation only triggers on distribution of the software, and a company that runs a modified version only as an internal or hosted network service, never actually distributing a copy to anyone, was never legally required to disclose its modifications under GPL alone. AGPL extends the same source-disclosure obligation to anyone who runs a modified version of the software as a network service that users interact with remotely, not only to those who receive a distributed copy (GNU Affero General Public License v3.0). This is precisely the “SaaS loophole” that motivated several of the real relicensing decisions covered in the next section.
Source-available licenses are not the same as open source
The Open Source Initiative (OSI) maintains a specific, ten-point Open Source Definition (OSD) that a license must satisfy to be called “open source” with OSI's approval, and one of those ten criteria — no discrimination against fields of endeavor — is precisely where licenses like the Business Source License (BSL/BUSL), the Server Side Public License (SSPL), and the Elastic License 2.0 fail to qualify (Open Source Initiative, The Open Source Definition). The Business Source License, originally authored by MariaDB Corporation, makes source code visible and modifiable but restricts production or commercial use until a specified future “Change Date,” after which the license automatically converts to a genuinely open-source license the author names in advance (often Apache 2.0 or MPL). The Server Side Public License, authored by MongoDB and based on AGPLv3, broadens AGPL's network-service disclosure trigger significantly: it requires that anyone offering the licensed software as a service make substantially the entire service stack that delivers it — not merely their modifications to the software itself — available as open source. The Elastic License 2.0 permits use, copying, and modification but explicitly prohibits providing the software to third parties as a hosted or managed service, prohibits circumventing license-key functionality, and prohibits removing licensing notices.
The practical distinction worth internalizing: “source-available” means the code is visible and often modifiable, while “open source” specifically means a license that meets OSI's full Open Source Definition, with no carve-out restricting who can use it or for what. A company describing BSL- or SSPL-licensed code as “open source” in marketing materials is using the term more loosely than OSI's own definition supports — a distinction worth being precise about internally even when the marketing language elsewhere is looser.
A Real History of Relicensing Controversy
Have real companies actually reversed their open-source licensing decisions, and what happened when they did?
Yes — four well-documented cases in six years. MongoDB moved from AGPL to the Server Side Public License in October 2018. Elastic moved from Apache 2.0 to SSPL and the Elastic License in January 2021, prompting AWS to fork Elasticsearch into OpenSearch months later. HashiCorp moved from the Mozilla Public License to the Business Source License in August 2023, prompting the OpenTofu and OpenBao community forks. Redis moved from BSD to a dual-license model in March 2024, prompting the Linux Foundation-backed Valkey fork.
MongoDB was first: on October 16, 2018, MongoDB announced the new Server Side Public License for MongoDB Community Server, moving away from AGPL (MongoDB Newsroom, October 16, 2018). MongoDB's own stated reasoning was that AGPL's network-service disclosure trigger still left a practical gap: a large cloud provider could host MongoDB as a managed service without necessarily triggering AGPL's obligations in a way MongoDB considered adequate, so SSPL was written specifically to require that anyone offering the software as a service open-source essentially their entire service stack, not just their modifications to MongoDB itself.
Elastic followed in January 2021, moving Elasticsearch and Kibana from Apache 2.0 to a dual SSPL/Elastic License model. Elastic founder and CEO Shay Banon wrote directly, in the company's own blog post announcing the change, that the motivation was competitive: large cloud providers — naming AWS specifically — were offering Elasticsearch as a managed service and, in Elastic's own characterization, capturing significant value without contributing back to the project (Elastic Blog, “Doubling down on open, Part II,” January 2021). AWS responded by forking the last Apache-licensed versions — Elasticsearch 7.10.2 and Kibana Dashboards 7.10.2 — into a new project called OpenSearch, announced in April 2021. OpenSearch has continued as an independent project since; in September 2024, AWS placed OpenSearch's governance under the Linux Foundation (TechCrunch, “AWS brings OpenSearch under the Linux Foundation umbrella,” September 16, 2024). In a notable reversal three and a half years later, Elastic added AGPL v3 — a genuinely OSI-approved open-source license — as a third licensing option alongside SSPL and the Elastic License, in a blog post titled directly “Elasticsearch Is Open Source. Again.” (Elastic Blog, August 29, 2024).
HashiCorp announced its own move away from open source on August 10, 2023, shifting Terraform, Vault, Consul, Boundary, Nomad, Waypoint, Packer, and Vagrant from the Mozilla Public License 2.0 to the Business Source License (HashiCorp Blog, “HashiCorp adopts the Business Source License for future releases of its products,” August 10, 2023). Within weeks, a community effort to fork Terraform's last MPL-licensed release began, and by September 20, 2023 the fork had a name — OpenTofu — and a home at the Linux Foundation (Linux Foundation Press, “Linux Foundation Launches OpenTofu,” September 20, 2023). A parallel fork of Vault, called OpenBao and originated in part by IBM engineers, was also created under the Linux Foundation in response to the same August 2023 relicensing, though this guide could not independently confirm OpenBao's exact founding date beyond secondary reporting placing it around late 2023.
Redis was the most recent: on March 20, 2024, Redis announced a move from its long-standing three-clause BSD license to a dual Redis Source Available License (RSALv2) and Server Side Public License (SSPLv1) model, applying starting with Redis 7.4 and all future releases while leaving Redis 7.2.4 and earlier versions BSD-licensed and unaffected (Redis Blog, “Redis Adopts Dual Source-Available Licensing,” March 20, 2024). Within roughly a week, a group including former Redis maintainers, AWS, Google, Oracle, and Ericsson announced Valkey, a BSD-licensed fork of Redis 7.2 hosted by the Linux Foundation — this guide found the announcement dated to either March 28 or April 1, 2024 across different secondary sources, and could not resolve the exact day with full confidence in this research pass, though the Linux Foundation's sponsorship and the fork's BSD licensing are both well corroborated.
| Company | License Change | Date | Resulting Fork |
|---|---|---|---|
| MongoDB | AGPL → SSPL | October 16, 2018 | None documented |
| Elastic | Apache 2.0 → SSPL / Elastic License | January 2021 | OpenSearch (AWS, April 2021) |
| HashiCorp | MPL 2.0 → Business Source License | August 10, 2023 | OpenTofu / OpenBao (Sept–Dec 2023) |
| Redis | BSD → dual RSALv2 / SSPLv1 | March 20, 2024 | Valkey (Linux Foundation, 2024) |
The pattern across all four cases is consistent and worth stating plainly: each relicensing was justified publicly as a response to large cloud providers monetizing the company's own open-source work as a competing hosted service without contributing back, and two of the four (HashiCorp and Redis) directly produced a community fork within weeks, hosted by the vendor-neutral Linux Foundation and backed in part by the very cloud providers the relicensing was aimed at. This is not a hypothetical risk being described in the abstract — it is a repeated, real, dated pattern with four independent data points.
Contributor License Agreements and Relicensing Optionality
How were MongoDB, Elastic, and HashiCorp able to relicense their projects unilaterally, when open-source projects usually have many outside contributors?
Each of these companies required outside contributors to sign a Contributor License Agreement (CLA) before accepting their code, which assigns or broadly licenses the contributor's copyright to the company itself. Holding that consolidated copyright is what let the company relicense the entire project's future releases unilaterally, without needing separate permission from every individual past contributor.
This is a widely reported and structurally significant mechanism worth naming directly, because it is the real answer to a question a team evaluating any of these relicensing events should immediately ask: how can one company change the license on a project that dozens or hundreds of outside developers contributed to? The practical mechanism, common across large corporate-backed open-source projects, is a Contributor License Agreement required before a company accepts an outside pull request — the agreement typically grants the company a broad enough license (or an outright copyright assignment) that the company, not the individual contributor, ends up holding sufficient rights to relicense the combined codebase going forward. A project without CLAs, governed instead by a foundation holding no single company's consolidated copyright — the Apache Software Foundation's governance of Kafka is the clearest contrast already named above — cannot be unilaterally relicensed by any single contributing company for exactly this reason, which is a structural, not merely rhetorical, difference between a corporate-controlled open-source project and a foundation-governed one.
The practical implication for a company weighing its own open-source strategy from the outset: requiring a CLA from contributors preserves the option to relicense later, at some real cost to contributor goodwill and community trust, while donating a project to a neutral foundation (as OpenTofu and Valkey both did immediately upon forking, landing at the Linux Foundation in both cases) makes a future unilateral relicense structurally impossible without the same kind of controversy that produced those forks in the first place. This is a real, concrete decision a company makes at a project's founding — often long before anyone anticipates ever wanting to relicense — and it is worth making deliberately rather than defaulting to whichever contribution-agreement template a company's legal team happens to reach for first.
A related, complementary lever worth naming directly: licensing the code and controlling the trademark are two separate legal mechanisms, and a company can open-source its code fully while still retaining exclusive rights to the product name and logo. Elastic's dispute with AWS is widely reported to have involved exactly this second lever alongside the licensing dispute covered above — Elastic pursued trademark claims over AWS's use of the “Elasticsearch” name in its own branded service offering, a dispute this guide did not independently verify to an exact date in this research pass and is naming here as a widely reported detail rather than a fully confirmed one. The broader, structurally simple point stands regardless of that specific case's exact details: even a company that open sources its code under the most permissive license available can still prevent a competitor from using the product's own brand name to market a competing hosted version, which is a real, separate point of leverage worth understanding as distinct from the license question this guide has otherwise focused on.
Dual Licensing: An Older, Different Model
Is dual licensing the same thing as the relicensing controversies above?
No — dual licensing means offering the same software under two different licenses simultaneously from the start (typically GPL for free use and a separate commercial license for companies that cannot accept GPL's obligations), rather than changing an existing license after the fact. MySQL is the most historically significant real example, and its later corporate history — two acquisitions and a resulting community fork — is itself a distinct, real, documented case worth knowing.
MySQL AB offered its database under a dual-license model from early in the product's life: a GPL license free for open-source and personal use, and a separate commercial license for companies that wanted to embed MySQL in a proprietary product without triggering GPL's copyleft obligations. This model is structurally different from everything covered above — it was the license structure from the start, not a later relicensing away from an existing open commitment, and it let MySQL AB monetize commercial use while keeping the same codebase genuinely GPL-licensed for everyone else simultaneously.
MySQL AB's later corporate history produced a separate, real fork worth knowing as a fifth data point alongside the four relicensing-driven forks above, because it shows a fork triggered by a change in corporate stewardship rather than a license change. Sun Microsystems acquired MySQL AB in 2008, and Oracle then acquired Sun in 2010, making Oracle the steward of MySQL. MySQL co-founder Michael “Monty” Widenius — the same Michael Widenius who later founded MariaDB Corporation and authored the Business Source License referenced earlier in this guide — created MariaDB as a GPL-licensed fork of MySQL in 2009, before the Oracle acquisition closed, citing concerns about the database's future stewardship under new corporate ownership. MariaDB has continued as an independent, widely-adopted project since, distributed by default in several major Linux distributions in place of MySQL.
The practical lesson from MySQL's history is distinct from the lesson in the relicensing section above: a fork can happen even without any license change at all, purely because a community loses confidence in who now controls a project's direction after an acquisition. A company considering open-sourcing part of its product under a dual-license model should weigh not only the license terms themselves but also what happens to community trust if the company itself is later acquired — a risk dual licensing does not eliminate, since MySQL's own dual-license structure survived two acquisitions intact while community trust in Oracle's stewardship did not.
The Open-Core Model
What is the open-core business model, and does it actually work?
Open core means releasing a functional core product as genuinely open source while monetizing additional proprietary features, extensions, or an enterprise tier built on top of that core. GitLab is the most directly documented real example: its Community Edition is MIT-licensed and open, while its Enterprise Edition contains proprietary features gated behind paid plans.
GitLab's own July 2016 blog post describing itself as “open core” remains the clearest primary-source articulation of the model from a company actually running it: individual and core version-control functionality (branching, merge requests, CI) ships in the MIT-licensed Community Edition, while collaboration-at-scale and enterprise-administration features sit in the proprietary Enterprise Edition that paying organizations license. The commercial logic is direct: an individual developer or a small team can adopt GitLab CE at zero cost, building genuine familiarity and internal advocacy for the product, and the paid conversion happens later, when an organization needs the management and governance features an individual developer never needed.
It is worth being precise about a term this guide could not fully verify: the phrase “open core” is widely attributed to a 2008 coinage by consultant Andrew Lampitt, and that attribution appears consistently across secondary sources describing the term's history. This guide could not, in this research pass, locate and directly confirm Lampitt's original 2008 post itself, so the exact date and source text of the original coinage should be treated as well-corroborated but not independently verified against a primary document.
Real, Documented Risks of Open-Sourcing
What are the real, documented risks of open-sourcing part of a commercial product?
Two are directly documented with specific, dated public cases: a large cloud provider forking and monetizing the software as a competing managed service without contributing back (the AWS/Elasticsearch case above is the clearest real example), and a genuine, survey-documented maintainer burden — a majority of open-source maintainers report being unpaid, and a majority have quit or considered quitting maintenance work. A third real, structural risk — accidental exposure of internal implementation details or credentials left in a codebase's git history — is harder to attach to one dated public incident but is a genuine engineering hazard worth auditing for before any release.
Tidelift's maintainer research, published across 2023 and 2024, is the most directly cited real survey data on this specific risk: roughly 60% of maintainers surveyed remain unpaid for their work, and of those, a large share report the work adds real stress to their lives, with a majority reporting they have quit or seriously considered quitting maintenance work altogether (Tidelift / BusinessWire, May 2, 2023; Tidelift / BusinessWire, September 17, 2024). Tidelift's later 2024 release adds a directly relevant finding for a commercial company deciding whether to fund its own open-source maintenance: paid maintainers were meaningfully more likely to implement recognized critical security and maintenance practices (measured against frameworks like the OpenSSF Scorecard and NIST's Secure Software Development Framework) than unpaid maintainers were. This guide is presenting these figures as reported in Tidelift's own press materials rather than having independently re-derived them from Tidelift's raw survey data, which is worth noting as a limit on precision even though the source itself is real, named, and dated.
A third risk worth naming directly, even though this guide could not attach a specific dated public case to it with full confidence, is accidental intellectual-property leakage: a team open-sourcing part of a codebase that was originally written as fully proprietary can inadvertently expose internal implementation details, unreleased feature code left in a shared repository history, hardcoded internal hostnames or configuration patterns, or logic that reveals more about a company's internal pricing or business rules than the team intended when the open-source release was scoped. This is less a single documented incident than a real, structural risk inherent to the mechanics of open-sourcing an existing proprietary codebase rather than one built open from day one: git history itself, not just the current state of the files, needs deliberate review before a repository goes public, since a deleted line still exists in every prior commit unless the history itself is explicitly rewritten or the repository is republished fresh without its original history. A team open-sourcing part of a product for the first time should treat this as a real pre-release engineering task — auditing commit history, checked-in credentials, and internal-only comments — not an afterthought to be caught after the fact.
The competitive-forking risk is the one already documented in full above: Elastic's own January 2021 blog post named the concern directly and explicitly, and AWS's April 2021 OpenSearch fork is a real, dated response that validated the concern was not hypothetical. The practical lesson for a company considering open-sourcing part of a commercial product is not that open-sourcing is unsafe in general — GitLab's open-core model has run for close to a decade without a comparable relicensing reversal — but that a company whose core product is easily operated as a hosted service by a well-resourced cloud provider carries a specific, real, and previously realized risk that a company shipping developer tooling, CLIs, or SDKs generally does not carry in the same way.
Open Source as a Hiring and Adoption Signal — What's Actually Verifiable
Is there real data supporting open source as a developer hiring or adoption signal?
Partially. Stack Overflow's own 2019 Developer Survey found roughly 65% of professional developers contribute to open-source projects at least once a year, and GitHub's Octoverse reporting states roughly 70% of Global Fortune 50 companies made an open-source contribution in a recent year — both real, named, dated sources. A more specific claim commonly repeated in marketing content — that having an open-source presence measurably increases a company's ability to hire developers — could not be traced to a specific, dated primary survey in this guide's research.
Stack Overflow's 2019 Developer Survey is a real, named, dated source worth citing directly: approximately 65% of professional developers surveyed reported contributing to open-source projects at least once a year, with contribution rates varying meaningfully by primary language and ecosystem (Stack Overflow Developer Survey 2019). GitHub's own Octoverse research separately reports that roughly 70% of Global Fortune 50 companies made an open-source contribution in the year covered by its 2019 report, and GitHub's own more recent Octoverse materials describe open source as underpinning the large majority of the world's software (GitHub Octoverse 2019). Both of these are genuine, dated, sourced figures worth citing — but it is worth being precise that they measure developer participation in open source generally, not a direct, measured causal link between a specific company having open-source repositories and that company finding it easier to hire.
This guide searched directly for a dated, named survey specifically measuring whether developers are more likely to apply to or consider a company because of its open-source presence, and could not locate one that met this series' verification standard. The claim is extremely common in developer-marketing and developer-relations content, and it may well be directionally true, but presenting an invented percentage attached to that specific claim would be exactly the kind of fabrication this series exists to avoid — so it is named here explicitly as a commonly repeated but unverified claim rather than silently treated as established fact.
| Path | Real Example | What Actually Happened |
|---|---|---|
| Sustained open core, no relicense | GitLab (CE open since founding, EE proprietary) | Nearly a decade of open-core operation with no comparable relicensing reversal, per GitLab's own public documentation of the model |
| Fully permissive, later relicensed | MongoDB, Elastic, Redis (originally AGPL/Apache/BSD) | Each relicensed after a cloud provider began offering the software as a competing managed service; Elastic and Redis both produced community forks in response |
| Business Source License from a later point | HashiCorp (moved from MPL 2.0 in Aug 2023) | Produced the OpenTofu and OpenBao Linux Foundation forks within weeks, the fastest fork response of the four documented cases |
| Foundation-governed from the start | Apache Kafka (Apache Software Foundation) | No single company holds consolidated copyright, so no unilateral relicense is structurally possible — Confluent's own licensing moves apply only to its separate Confluent Platform components, not Kafka itself |
A Practical Decision Framework: What to Open-Source vs. Keep Proprietary
Bringing the research above together into an actual sequence for a team weighing this decision for the first time:
Could a well-resourced cloud provider trivially re-host this as a service?
If yes — the product is primarily a hosted-infrastructure category like a database, cache, or search engine — the AWS/Elasticsearch and Redis/Valkey precedent applies directly, and a source-available license or a genuinely defensible open-core split deserves serious consideration before defaulting to a fully permissive license.
Draw the open-core line around the individual-vs-organization boundary
GitLab's own real split — individual and core functionality open, organization-scale management features proprietary — is the most directly documented working example of where this line can sit.
Choose the license for what it's actually for, not for its reputation
MIT/Apache for maximum adoption with no disclosure obligation; AGPL specifically when the goal is closing the SaaS loophole while remaining OSI-approved open source; a source-available license like BSL only when the explicit goal is delaying commercial competition for a defined period.
Budget real, ongoing maintenance — not just the initial release
Tidelift's own data ties paid maintenance directly to better security practices; an unfunded open-source release that a company treats as a one-time marketing event rather than an ongoing commitment is a real, documented failure pattern, not a hypothetical one.
It is worth being direct about the order these four steps belong in, since a team new to this decision often reaches for the license question first, before doing the harder strategic work the earlier steps require. Choosing between MIT, Apache, AGPL, or a source-available license is a real decision with real consequences, but it is a downstream decision — it only makes sense once a team has already decided what specifically it is open-sourcing and why, which is exactly the assessment and split steps above. Skipping straight to the license question, the way a surprising amount of informal advice on this topic does, risks producing a legally coherent license attached to a strategically incoherent scope.
None of the four real relicensing cases above happened because the company's original choice to open source was wrong in principle — each company built genuine adoption and community trust from its original open license before relicensing. The lesson from the real, dated history is narrower and more useful: a company whose product category makes it trivially easy for a much larger, better-resourced cloud provider to operate the same software as a competing service should treat that specific risk as a real, foreseeable cost of a fully permissive license from the outset, weighing it explicitly against the adoption benefit rather than discovering the tradeoff only after a competitor has already captured the value.
What This Guide Could Not Verify
Consistent with the standing rule across this series, it's worth naming directly the specific claims this guide's research could not confirm to a standard it's comfortable presenting as settled fact:
- 1
The exact day of Elastic's January 2021 relicensing announcement
Secondary sources cite January 14, 18, and 21, 2021 inconsistently; this guide uses "January 2021" throughout rather than asserting a specific day.
- 2
OpenBao's exact founding or announcement date
Secondary reporting places it in late 2023, generally described alongside OpenTofu, but this guide could not confirm an exact date against a primary Linux Foundation announcement.
- 3
Valkey's exact announcement date
Secondary sources place the Linux Foundation announcement on either March 28 or April 1, 2024; this guide could not resolve the discrepancy with full confidence.
- 4
Andrew Lampitt's original 2008 coinage of "open core"
Widely and consistently attributed to Lampitt across secondary sources, but this guide could not locate and directly confirm his original 2008 post.
- 5
A direct, dated survey measuring open source as a hiring signal specifically
Stack Overflow and GitHub Octoverse data measure open-source participation broadly and are cited directly above, but no dated primary source was found measuring whether open-source presence specifically increases a company's ability to hire — this common claim should be treated as plausible but unverified.
- 6
The exact date and outcome of Elastic's trademark dispute with AWS
Widely reported as a real dispute over AWS's use of the "Elasticsearch" name, separate from the licensing dispute covered in detail above, but this guide could not confirm its exact filing date or final resolution against a primary source in this research pass.
Frequently Asked Questions
What is the difference between "open source" and "source-available"?
Open source specifically means a license approved by the Open Source Initiative against its ten-point Open Source Definition, which prohibits discriminating against fields of use. Source-available licenses like the Business Source License and SSPL make code visible and often modifiable but explicitly restrict certain commercial or competitive uses, which disqualifies them from OSI approval.
Why did MongoDB, Elastic, HashiCorp, and Redis all relicense away from open source?
Each company stated a similar public rationale: large cloud providers were operating their open-source software as a competing hosted service without contributing back. MongoDB moved to SSPL in October 2018, Elastic in January 2021, HashiCorp to the Business Source License in August 2023, and Redis to a dual license in March 2024.
What happened after HashiCorp and Redis relicensed?
Both produced real, dated community forks hosted by the Linux Foundation: OpenTofu and OpenBao forked from HashiCorp's Terraform and Vault within weeks of the August 2023 announcement, and Valkey forked from Redis within roughly a week of the March 2024 announcement, backed in part by AWS, Google, Oracle, and Ericsson.
What is the "open core" business model?
Releasing a functional core of a product as genuinely open source while monetizing additional features, extensions, or an enterprise tier on top of it. GitLab is the clearest documented example, with an MIT-licensed Community Edition and a proprietary Enterprise Edition.
Does AGPL actually solve the "SaaS loophole" that led companies like MongoDB to relicense?
AGPL extends GPL's disclosure obligation to network-service use, not just distribution, which is a real, meaningful closing of the loophole GPL alone leaves open. MongoDB's own SSPL goes further than AGPL by requiring disclosure of the entire service stack that delivers the software, not just modifications to the software itself — which is part of why MongoDB chose to write a new license rather than simply adopting AGPL.
Is open-sourcing part of a product actually risky?
There are two real, documented risks: a well-resourced cloud provider forking and monetizing the software as a competing service without contributing back, and a genuine, survey-documented maintenance burden if the company doesn't fund ongoing maintenance. Neither risk means open-sourcing is a bad strategy in general — GitLab's open-core model has run for close to a decade — but both are real, not hypothetical.
Is there real data on open-source maintainer burnout?
Yes — Tidelift's 2023 and 2024 maintainer research found roughly 60% of maintainers surveyed remain unpaid, with a majority reporting the work adds stress to their lives and a majority having quit or considered quitting maintenance work.
Does having open-source projects actually help a company hire developers?
Real data shows developers broadly participate in open source (roughly 65% contribute annually per Stack Overflow's 2019 survey) and that most large companies contribute to open source (per GitHub's Octoverse research), but this guide could not locate a dated, primary survey directly measuring whether open-source presence specifically increases a company's ability to hire — that specific claim should be treated as plausible but unverified.
What is "Fair Source," and how is it different from open source?
Fair Source is a source-available licensing model Sentry announced adopting on August 6, 2024, explicitly trading full OSI open-source status for continued business sustainability. Like BSL and SSPL, it is not OSI-approved open source — Sentry itself frames the tradeoff as a deliberate choice between full openness and a company's ability to keep funding development.
How could MongoDB, Elastic, and HashiCorp relicense projects that had many outside contributors?
Each required a Contributor License Agreement (CLA) from outside contributors before accepting their code, which consolidated enough rights in the company itself to relicense future releases unilaterally. A foundation-governed project without CLAs, like Apache Kafka under the Apache Software Foundation, cannot be relicensed this way by any single company.
What is dual licensing, and how is it different from a company relicensing later?
Dual licensing means offering the same software under two licenses simultaneously from the start — typically GPL for free use and a commercial license for companies that can't accept GPL's terms — rather than changing an existing license after the fact. MySQL AB is the classic real example; its later fork into MariaDB in 2009 was driven by a change in corporate ownership (Sun's 2008 acquisition, then Oracle's 2010 acquisition of Sun), not a license change.
Every relicensing date, fork, and survey figure in this guide traces to a real, named, dated source — a company's own blog post, a press release, or a named survey — and every place this guide's research hit a genuine limit, that limit is stated directly rather than papered over with an invented date or an unattributed statistic. A company deciding whether to open-source part of its own product is making a real strategic bet with a documented, six-year history of both paying off and backfiring, and that history is worth reading directly rather than through secondhand summary.