Software Licensing and Vendor Lock-In: The Legal History Every Builder Needs

A technology choice is also a legal choice. The code can be excellent, the docs can be clear, the community can be huge, and the contract can still ruin you. Beginners pick tools by features and benchmarks, then discover too late that a license clause or a renewal term controls their future.

The license spectrum

Licenses sit on a spectrum from total freedom to total vendor control. The diagram below moves from the most permissive at the top to the most restrictive at the bottom. Most of the pain comes from teams that assume the source is visible and the rights are open. Those are two different things.

What each category actually means

Public domain means no one holds rights. With a tool like CC0, you can do anything with the code and owe nothing in return. This is rare for full applications and more common for small snippets or sample code.

Permissive licenses let you use, modify, and redistribute the code, including inside closed commercial products. You keep the original copyright notice, and that is almost the only rule. MIT, Apache 2.0, and BSD are the big three. Apache 2.0 adds an explicit patent grant, which is why large companies favor it.

Copyleft licenses also grant broad rights, but they attach a condition. If you distribute software built on copyleft code, you must release your changes under the same license. The GNU General Public License (GPL) covers distributed software. The Affero GPL (AGPL) closes the network gap, so running modified code as a hosted service also triggers the share-back rule. Copyleft keeps derivatives open, which some companies treat as a risk.

“Open source” has a precise meaning. The Open Source Initiative (OSI) maintains the Open Source Definition. To qualify, a license must grant four freedoms: the freedom to use the software for any purpose, study how it works, modify it, and redistribute it (including commercially). Permissive and copyleft licenses both meet this bar.

Source-available is not the same thing. Licenses like the Business Source License (BSL), the Server Side Public License (SSPL), and the Elastic License let you read the source and often modify it. They also forbid certain uses, usually offering the product as a competing managed service. Because they restrict use, the OSI does not recognize them as open source. The source being visible does not make the license open. This single distinction is the root of the relicensing wars below.

Proprietary software ships as a binary. You get no source, you cannot modify it, and the vendor controls pricing, terms, and your exit. This is normal for commercial products, but it concentrates risk in the contract.

The relicensing wars

A pattern repeats across the last decade of infrastructure software. A company builds a popular project under an open source license, grows a large community, then watches cloud providers sell that project as a managed service without paying back. The company responds by relicensing to a source-available license that blocks the cloud providers. The community, now cut off from open terms, forks the project under its old license. Below is that playbook as a flow.

These are the real events, in order.

MongoDB (2018). On 2018-10-16, MongoDB relicensed its Community Server from AGPLv3 to its own Server Side Public License (SSPL). The SSPL requires any organization offering MongoDB as a service to open source the entire stack used to run that service. The target was cloud providers selling managed MongoDB. The OSI did not accept the SSPL as an open source license.

Red Hat and CentOS (2020). CentOS Linux was a free rebuild of Red Hat Enterprise Linux (RHEL), used widely as a no-cost server base. On 2020-12-08, Red Hat ended CentOS Linux in favor of CentOS Stream, a rolling preview that sits upstream of RHEL rather than downstream. The move cut CentOS 8 support from 2029 to the end of 2021. The backlash produced two new free RHEL rebuilds: Rocky Linux and AlmaLinux.

Elastic (2021). On 2021-01-14, Elastic moved Elasticsearch and Kibana from Apache 2.0 to a dual license of SSPL and the Elastic License. The aim was Amazon’s managed Elasticsearch service. AWS responded by forking both projects into OpenSearch under Apache 2.0. Elastic later re-added an AGPLv3 option in 2024, restoring an OSI open source path.

HashiCorp (2023). On 2023-08-10, HashiCorp relicensed Terraform and its other core products from the Mozilla Public License 2.0 (MPL 2.0) to the Business Source License (BSL). The community reacted within days. The OpenTF manifesto appeared on 2023-08-15, the fork became OpenTofu, and it joined the Linux Foundation on 2023-09-20. The BSL is source-available, not OSI open source, but it has a time fuse: each released version converts to MPL 2.0 four years after release.

Broadcom and VMware (2023). Broadcom completed its acquisition of VMware on 2023-11-22. On 2023-12-11, it ended perpetual VMware licenses and moved customers to subscription-only bundles. Existing customers with perpetual licenses must convert to subscription at renewal. The change drove sharp price increases and forced many teams to re-evaluate their virtualization platform.

Oracle and Java. Oracle has changed Java licensing several times, including a per-employee subscription model that prices the whole organization rather than the users who actually run Java. Many buyers were surprised by audits and bills well above what they expected. It is a reminder that commercial license terms can shift under a tool you already depend on.

Vendor lock-in

Vendor lock-in is the cost of leaving. The higher that cost, the more power the vendor holds over your roadmap, your budget, and your terms. Lock-in is rarely one big trap. It builds quietly through dependencies that feel convenient at the time.

It bites in four common places.

• Data formats. When your data lives in a proprietary format, exporting it cleanly is hard or impossible. Your records become hostage to one product.
• Proprietary APIs. Code written against a vendor-specific API will not move to a competitor without a rewrite. Every integration deepens the dependence.
• Perpetual-to-subscription shifts. A tool you bought once can become a tool you rent forever. The VMware change shows how fast a paid-up asset turns into a recurring cost.
• Deep platform dependence. Heavy reliance on a single ecosystem, like SAP for business processes or one cloud for everything, ties your operations to one vendor’s pricing and survival.

Comparing the categories

This table shows the four working categories side by side. “Can a competitor offer it as a service” is the clause that started the relicensing wars.

How to protect yourself

You cannot stop a vendor from changing its license. You can stop that change from being a crisis. Treat licensing and exit cost as engineering decisions, not legal afterthoughts.

• Make exit cost a first-class selection criterion. Before you adopt a tool, ask how you would leave it. If the answer is “we could not,” that is your real total cost.
• Read the license before you build on it. Know whether it is permissive, copyleft, source-available, or proprietary. Do not assume “open” because the source is on GitHub.
• Prefer foundation-governed projects. Tools held by the Linux Foundation, the Apache Software Foundation, or the Cloud Native Computing Foundation (CNCF) cannot be relicensed at one company’s whim. Shared governance is a structural protection.
• Favor open standards and data portability. Choose formats and protocols you can export and import elsewhere. Portable data is the difference between switching vendors and being stuck.
• Keep a fallback for free tiers. A generous free tier is a business decision the vendor can reverse. Know your paid path and your alternative before you depend on it.
• Consider source code escrow for critical proprietary software. An escrow agreement releases the source to you if the vendor fails or breaches terms. For a system you cannot afford to lose, it buys continuity.
• Watch for the relicensing signals. A fast-growing single-company project under a permissive license, with cloud providers circling, is a candidate for the next relicense. Plan accordingly.

The lesson from the last decade is consistent. The teams that survived these changes had read the terms, valued portability, and knew their exit. The code was never the problem. The contract was.

Further reading

• The history of IT : how computing, networks, and the open source movement reached this point.
• What is open source : the OSI definition and why “source-available” is not the same thing.
• Terraform : the tool at the centre of the 2023 BSL relicensing and the OpenTofu fork.
• Service lifecycle and deprecation : how vendors retire products and shift terms, and how to plan for it.
• HashiCorp adopts the Business Source License : the official announcement that triggered the OpenTofu fork.
• Linux Foundation announces OpenTofu : the foundation-governed open source fork of Terraform.
• Open Source Initiative licenses : the authoritative list of OSI-approved open source licenses and the Open Source Definition.