How auditors and vendors find your exposure.

A relicense changes the incentives of the company that owns the project. Software that was free to use in production now sits behind terms that can require a commercial license for certain uses. The owner has a business reason to find out who crossed that line, and a growing set of tools to do it. The teams that fare best are the ones who already know what an auditor would find, because they mapped it themselves before anyone asked.

How auditors and vendors find your exposure in practice

Auditors and vendors find your exposure by combining two kinds of evidence: public signals they can gather without your help, and contractual rights that let them ask you directly. Neither alone proves much. Together they build a picture detailed enough to open a conversation with a number attached. The mistake buyers make is assuming internal usage is invisible. It is far more visible than it feels, and the gap between what you think is private and what is actually inferable is where surprises live.

This matters most for the projects in the relicensing wave. As of August 2023, HashiCorp moved Terraform, Vault, Consul, Nomad, and Packer to the Business Source License 1.1. As of March 2024, Redis moved to the Redis Source Available License and the Server Side Public License. Elasticsearch and Kibana moved to the Server Side Public License and the Elastic License in 2021, and MongoDB moved to the Server Side Public License in 2018. Each of these owners has both the motive and the means to ask how you use their software now.

The public signals they read first

Long before any formal inquiry, a vendor can assemble a strong hypothesis from what your organization publishes. Job postings that ask for experience with a specific tool tell them the tool is in your stack. Conference talks and engineering blog posts describe architectures in detail. Public code repositories, container image manifests, and dependency files leak component names and versions. Even support forum questions from employees point to what is running. None of this is secret, and all of it is searchable. A capable analyst can build a credible map of your estate from open sources alone.

Telemetry adds another layer. Some distributions phone home with version and usage data when a binary runs. Download records tied to a registered account connect a company to specific releases. None of these signals are conclusive on their own, but they narrow the field and tell a vendor where to focus. By the time an account team reaches out, they usually already believe they know the answer and are looking for confirmation.

The contractual rights that let them ask directly

Public signals point the way. Contracts let a vendor confirm. Many support agreements, enterprise subscriptions, and commercial licenses carry an audit clause that grants the vendor the right to verify your usage. Some rely on self reporting, where you attest to your deployment. Others permit a third party review of your environment. After a relicense, a vendor can use an existing support relationship as the doorway to a usage review of the newly restricted software. The clause you signed years ago for a different product can become the lever applied to the relicensed one.

This is why reading your existing agreements matters as much as scanning your code. The exposure is not only technical. It is contractual, and the terms that govern an audit were often agreed to before the relicense made them sharp. Your own counsel should interpret what a specific clause permits, but you need to know the clause is there before the vendor reminds you.

Where the inferences go wrong, for and against you

Inference is not proof, and that cuts both ways. A vendor may assume a component is in production when it only ever ran in a test environment. They may attribute a use to your offering when it sits behind an internal tool the license does not restrict. Left uncorrected, these assumptions inflate the number a vendor brings to the table. The buyers who control the conversation are the ones who can answer each assumption with evidence: this ran here, under these terms, for this use, since this date. Without that evidence, you are negotiating against the vendor's worst case version of your estate.

How to map your exposure before anyone asks

The defense is to know your estate better than the party asking the questions. Start with a complete inventory through software composition analysis, reaching the transitive layers where relicensed components often hide. Record the current license state of each component rather than the license declared when you adopted it. Then classify each use: internal only, customer facing, or part of an offering the license might restrict. That three part record is what turns an open ended inquiry into a bounded, answerable question. When a vendor arrives with a hypothesis, you meet it with a map.

Doing this first also reveals exposure you would rather fix quietly than defend loudly. If a relicensed component is running where the license restricts it, you may choose to migrate to a fork such as OpenTofu, Valkey, or OpenSearch, remove the dependency, or negotiate a license on your terms. All of those options are easier before a vendor opens a file than after.

Turning the inquiry into a bounded question

Knowing how auditors and vendors find your exposure is the start of our open source license risk assessment service, which builds the evidence record before you need it. For the wider frame, read our pillar on open source license risk. To build the map itself, see how to map your open source blast radius and open source license risk and your SBOM. To understand where the exposure hides, read the hidden open source exposure in production.