Commercial Licensing for ISVs and Redistributors

If you build software that other organizations run, you are an independent software vendor or a redistributor, and commercial licensing for ISVs and redistributors is a category of its own. The reason is distribution. An enterprise that runs open source internally answers to its own use. An ISV that embeds the same component in a product and ships it to customers takes on a second set of obligations triggered by the act of distribution. Many licenses, both copyleft and source available, treat distributed use differently from internal use, and the terms that work for an end user can leave a redistributor exposed.

This article sits under the pillar on commercial licensing and pairs with our open source commercial license negotiation service. It speaks to product, legal, and commercial leaders at companies that ship software, and it focuses on the specific terms a redistributor has to get right.

Why distribution changes everything

The dividing line in open source obligations is often the moment you convey software to someone else. Internal use sits on one side of that line, and distribution sits on the other. Copyleft licenses make the distinction explicit. The GNU GPL attaches obligations when you distribute, and the GNU AGPL extends similar reach to providing the software over a network. For an ISV, shipping a product that embeds such code can pull those obligations into the product itself, including the requirement to make corresponding source available to recipients. An internal user never reaches that trigger, which is why the same component carries a different risk depending on what you do with it.

Source available licenses add their own twist. The Business Source License restricts competitive production use, and the Server Side Public License attaches strong conditions to offering the software as a service. A redistributor whose product competes with, or is offered in the same way as, the licensed component can find that the restriction lands squarely on its business model. Understanding exactly where your product sits relative to these triggers is the first step. For the concrete obligations that distribution creates, see the article on copyleft distribution obligations explained.

What an ISV should negotiate

When a commercial license is the right answer for an ISV, the terms differ from a standard end user agreement, and the differences are where the value sits. The first is explicit redistribution and embedding rights. A license that permits internal use says nothing about your right to ship the component inside a product, and that right has to be granted in clear language rather than assumed. The second is a pricing metric that fits an OEM model. Internal seats or nodes rarely describe how an embedded component is actually used downstream, and a metric built for end users can produce a bill that bears no relation to your economics.

Beyond rights and price, three terms deserve particular attention. Clarity on end customer obligations matters, because you do not want to pass hidden conditions to your own customers or be held responsible for their use. Audit clauses should account for downstream deployment rather than assuming a single site you control, a point covered in commercial license audit clauses to watch. And indemnity should reflect that you are placing the component in front of third parties, which raises the stakes on any claim. These are not edge cases for an ISV; they are the core of the deal.

When a relicense reaches an embedded component

The hardest situation for a redistributor is a relicense of a component already embedded in a shipped product. When a project moves from an open license to a source available one, the terms can reach the exact thing the redistributor does. The recent wave makes this concrete. The HashiCorp move to the Business Source License as of August 2023, the Redis move to the Redis Source Available License and the Server Side Public License as of March 2024, and the earlier Elasticsearch and Kibana move to the Server Side Public License and Elastic License in 2021 each changed the terms under a component that ISVs had embedded under earlier open licenses. The community forks, OpenTofu, Valkey, and OpenSearch, exist partly because redistributors needed an open path forward.

For a redistributor in this position, the options are the familiar three: take a commercial license sized for distribution, migrate to a fork, or replace the component. The right choice depends on how deeply the component is embedded, how your product is sold, and where your leverage sits. A usage baseline and a clear read of the new terms turn a vendor demand into a negotiation, and a fork in hand strengthens that position, as covered in using a fork as negotiation leverage. The throughline for an ISV is the same in every case: distribution changes the obligations, so the license you sign has to be written for what you actually do with the software.

RELATED READING