Open Source Compliance for Shipped Products

Open source compliance for shipped products is a different discipline from compliance for software you run inside your own walls. The moment a binary, an appliance, or an installable package leaves your building and reaches a customer, a set of obligations that may have stayed dormant becomes live. Attribution notices must travel with the code. Copyleft components may require you to offer source. A dependency that relicensed since you adopted it may no longer be safe to redistribute at all. The product team that knows what it ships, under which terms, and meets each obligation before release carries a defensible position. The team that does not is shipping liabilities along with features.

We write from the buyer side as an independent advisory paid only by the buyer. This is not legal advice. For interpretation of how a license applies to a product you distribute, we point you to your own counsel.

Why shipping changes the open source compliance picture

Many open source obligations are tied to a single trigger: distribution. A license can grant broad rights for use and impose its conditions only when the software is conveyed to someone else. This is why open source compliance for shipped products differs so sharply from compliance for internal systems. A component running on a server you control, serving your own employees, may attach almost no obligation. The same component compiled into a product you sell, embedded in a device you ship, or bundled into an on premise installation reaches the customer, and the distribution conditions attach. The license text does not change. What changes is whether the trigger has fired.

The practical consequence is that the same dependency tree carries two compliance profiles depending on how the software reaches its users. A software as a service product that keeps the binary on infrastructure you operate faces a lighter set of distribution obligations, though it can still meet network use conditions under licenses such as the GNU AGPL. An embedded, on premise, or downloadable product hands the code to the customer and faces the full weight of distribution terms. Teams that built their compliance habits around hosted software are frequently surprised when a new on premise edition, an appliance, or an SDK puts them squarely inside obligations they had never needed to meet.

The obligations that travel with a distributed product

The obligations fall into a few groups. The first is attribution and notice. Permissive licenses such as MIT and Apache 2.0 ask very little, but what they ask applies to copies you distribute. You must preserve copyright notices and license text, and the Apache 2.0 license adds requirements around stating changes and carrying its notice file. The discipline here is producing and shipping a complete and accurate set of notices, which sounds trivial and is in practice where many products fall short, because the notices are assembled by hand and drift out of step with the dependency tree.

The second group is copyleft. A strong copyleft license such as the GNU GPL can require that, when you distribute a work built on the component, you offer the corresponding source under the same terms. This is the obligation that most directly touches your own proprietary code, because the boundary between what is covered and what is not depends on how the component is combined and shipped. The lesser copyleft licenses, such as the GNU LGPL and the Mozilla Public License, draw narrower boundaries, but they still carry conditions that apply on distribution. We treat the mechanics of these reciprocal obligations in copyleft distribution obligations explained. The point for a product team is that copyleft components in shipped code are not a problem to discover at release; they are a design decision to make deliberately and document.

The third group is relicensing. A component that has moved from an open license to a source available one may restrict redistribution in exactly the way a shipped product depends on. HashiCorp moved Terraform, Vault, Consul, Nomad, and Packer to the Business Source License as of August 2023. Redis moved to a source available model as of March 2024. Elasticsearch and Kibana moved to the Server Side Public License and the Elastic License in 2021. Source available is not open source, and these licenses are not approved by the Open Source Initiative. If your product embeds or redistributes one of them, the version you ship and its exact license terms decide whether you have a clean path or a problem. A dependency that was safe to bundle under its old open license can become unsafe in a later version, which is why the license state of the precise version you ship is the only thing that counts.

Building compliance into the release process

The reliable way to meet these obligations is to wire the check into the release, not to run it as an occasional audit. That starts with an accurate bill of materials for what actually ships, direct and transitive, to the depth a real dependency tree reaches. The product binary frequently contains components no one consciously added, pulled in by a build tool or a transitive dependency, and a notice set that omits them is incomplete. From the inventory, each component is classified by license and by how it is combined and shipped, which determines the obligation. Permissive components feed the notice file. Copyleft components are flagged for a deliberate decision about whether they belong in the distributed work. Source available components are checked against the redistribution terms of the version being shipped.

The output is a release that carries its own evidence: the notices customers are owed, a record of which copyleft components are present and why, and a confirmation that nothing in the build has relicensed into terms that block redistribution. That record is also the foundation for responding if a claim ever arrives, a topic we cover in defending an open source compliance claim. A product that can produce this evidence on demand turns an open ended inquiry into a bounded one. The same rigor that protects a release also protects a deal, since an acquirer will run its own version of these checks, as set out in the open source due diligence checklist.

Where this fits in your broader exposure

Compliance for shipped products is one face of a larger picture. The components you distribute are also components you depend on, and the relicensing wave that complicates redistribution also complicates the cost and continuity of the software you run. A product team that maps its shipped tree has done much of the work needed to understand its operational exposure as well, because it is the same tree examined for a different obligation. This is why we treat shipped product compliance alongside acquisition diligence and copyleft analysis in the broader M and A and compliance pillar. For a product company, the discipline pays twice: it keeps each release defensible, and it produces the clean, current inventory that protects valuation if the company is ever sold. The work of producing that inventory and the red flag memo that goes with it is our open source M and A due diligence service.