OPEN SOURCE LICENSE RISK

Permissive vs copyleft vs source available, explained.

Permissive vs copyleft vs source available explained for the people who carry the risk. This article sets out what each license family allows, what it obligates, and where the real enterprise exposure sits, so a relicense never catches your policy off guard.

Most open source license risk traces back to a single confusion: treating every license with visible source code as if it were the same thing. It is not. Permissive vs copyleft vs source available is the distinction that decides whether a component is a quiet convenience or a live obligation. This article explains the three families plainly and shows where each one creates exposure.

Permissive licenses

Permissive licenses, such as MIT, BSD, and Apache 2.0, grant broad freedom with minimal conditions. You can use, modify, and redistribute the software, including inside proprietary products, as long as you preserve the copyright notice and, in the case of Apache 2.0, observe its patent and attribution terms. For most enterprises these licenses carry the lowest risk. The main discipline is attribution hygiene and keeping a record of what you use.

The risk with permissive components is rarely the license itself. It is complacency. Because permissive licenses ask so little, teams stop tracking them, and that habit becomes dangerous when a permissively licensed project later relicenses. The component you never worried about can change terms under you.

Copyleft licenses

Copyleft licenses require that derivative works, distributed under defined conditions, be released under the same license. The GNU GPL is the classic example. The GNU AGPL extends the obligation to software offered over a network, which closes the so called service gap that let providers run GPL software as a service without sharing changes. Copyleft is still open source and still approved by the Open Source Initiative. The risk is obligation, not restriction.

For an enterprise, copyleft matters most at the point of distribution. Running GPL software internally generally carries little obligation. Shipping a product that incorporates it, or offering AGPL software as a service, can trigger source disclosure requirements that conflict with a proprietary model. The exposure is real but predictable, and a clear policy handles it.

Source available licenses

Source available is the family driving current concern, and the one most often misread. Source available means you can see the code, but the license restricts what you may do with it. The Business Source License and the Server Side Public License are the leading examples, and neither is approved by the Open Source Initiative. They are not open source.

The Business Source License restricts competitive production use and converts to an open license after a delay, commonly four years. As of August 2023 HashiCorp moved Terraform, Vault, Consul, Nomad and Packer to the Business Source License 1.1. The Server Side Public License carries a strong service condition aimed at parties who offer the software as a service. As of March 2024 Redis moved to a model that includes the Server Side Public License, with the fork Valkey. Elasticsearch and Kibana moved to the Server Side Public License and the Elastic License in 2021, with the fork OpenSearch. MongoDB moved to the Server Side Public License in 2018.

Why source available is the trap

The danger is the assumption that visible source means open source. A policy written for permissive and copyleft licenses has no category for a competitive use restriction, so a relicensed component passes through unflagged. The terms can apply to software already running in production, which means the exposure accrues silently until an upgrade, an audit, or a deal brings it forward. Naming this family explicitly, in policy and in your dependency map, is the single most useful step. For the full treatment, read why source available is not open source.

How the three families compare in practice

Think of the families as a spectrum of obligation and restriction. Permissive licenses ask for little and restrict less. Copyleft licenses ask for reciprocity when you distribute. Source available licenses restrict how you may use the software, regardless of distribution. The practical risk for your organization depends less on the label than on how you deploy: a component run purely internally carries a different profile from the same component shipped in a product or offered as a service.

What to do with this distinction

Record the license family of every dependency, not just its name, and give source available its own category. Decide in advance how each family is treated, then wire that into intake so a relicense is caught early. When a change has already reached your estate, map the blast radius and size it. The open source license risk guide sets out the full method, and these companion articles go deeper on where exposure hides: open source license risk in containers and images and open source license risk for the board.

COMMON QUESTIONS

Questions buyers ask.

CONTAINMENT

Know which license family governs each dependency.

A confidential open source license risk assessment. Independent, buyer side, paid only by you.

Not ready to talk? Read the free open source license risk guides first.