Corresponding Source Code

What “Corresponding Source Code” Means in Practice

Corresponding source code is the complete, buildable source needed to reproduce the covered program as distributed under the GPL, including the material required to install and modify it. The key point is completeness: the obligation is satisfied by a real build path, not by a partial snippet, a vendor patch, or a source archive that omits essential files.

That distinction matters because software publishers often assume that “source available” is enough. For GPL-covered distribution, the question is whether a recipient can actually reconstruct the shipped work and make lawful modifications to it. In practice, that usually means preserving the source tree, build instructions, versioned dependencies where required, and any scripts or metadata needed to turn source into the delivered binary.

What Belongs in the Source Package

A compliant source package generally needs to mirror the distributed work closely enough that a third party can build the same program without reverse engineering the release artefact. For many organisations, this becomes a release-management problem as much as a licensing problem, because the packaging process must capture exactly what was shipped, not what engineering wishes had been shipped.

The most common failure is under-inclusion. Teams may provide application code but omit build scripts, generator outputs, interface definitions, or configuration needed to compile and link the program. That gap can turn a nominal source release into a non-functional one. The same issue appears when code is split across multiple repositories or when release engineering relies on generated artefacts that are not carried into the source bundle.

For background on how hidden code and secrets in repositories can create security exposure, see Guide to the Secret Sprawl Challenge and Emerald Whale breach, both of which show how repository content can become an exposure point when packaging and hygiene fail.

Why It Matters for Compliance and Software Distribution

Corresponding source code is not just a licensing formality. It defines the practical boundary between lawful redistribution and a release that may trigger compliance disputes, partner friction, or customer escalations. If the source cannot be produced reliably, the organisation can end up in the uncomfortable position of shipping binaries without being able to support the rights attached to them.

From an operational perspective, the requirement pushes teams toward disciplined provenance tracking, release manifests, and clear ownership over what counts as part of the distributed work. That is especially important when build pipelines assemble software from many modules, shared libraries, and generated components. The more complex the build, the easier it is to lose track of what must be included in the source package.

For a concrete example of how exposed code and credentials can travel together through repositories, see New York Times breach and Slack GitHub Breach. For broader control guidance on code and secret handling, OWASP’s API Security Top 10 is also useful for understanding how exposed interfaces and weak authorisation patterns amplify distribution mistakes.

How Organisations Should Interpret “Full” Source

“Full” does not mean a random dump of every repository the company owns. It means the complete source necessary for the covered work as distributed. That makes scoping important: legal, engineering, and release teams need a shared understanding of which artefacts are part of the product and which are merely adjacent internal assets.

A useful way to think about the term is through reproducibility. If a technically competent recipient could not build the shipped work from the provided materials, the package is probably incomplete. If the build depends on undocumented steps, private tooling, or omitted generator inputs, the package may also be incomplete even if the main application code is present.

Release teams often benefit from pairing source packaging with dependency review and build verification, so the published source aligns with the actual binary. That reduces the risk of accidental omission and makes it easier to demonstrate that the delivered source truly corresponds to the distributed work.

Risk and Threat Considerations

In practice, the main risk is not abstract licensing theory, but operational failure: incomplete source release can create compliance exposure, delay distribution, and force emergency reconstruction of lost build inputs. When repositories also contain secrets, tokens, or internal configuration, a source release process that is too loose can widen exposure beyond the GPL obligation itself.

Failure mechanism: The organisation treats a partial code export, an outdated repository snapshot, or a binary-only release note as if it were corresponding source, then discovers too late that build inputs, scripts, or generated files were missing.

Impact: The result can be non-compliant distribution, customer disputes, release delays, and a larger attack surface if sensitive material is unintentionally bundled with the source package.

Practitioner Guidance

Governance implication: Treat corresponding source code as a release-controlled deliverable with clear ownership between legal, engineering, and build/release operations. That ownership should cover scope, packaging criteria, and the evidence needed to show that the published source matches the shipped build.

Practitioner takeaway: If your organisation cannot rebuild the shipped artefact from the source package alone, the package is not yet a reliable corresponding source release.

Related resources from NHI Mgmt Group

• Why is hardcoding credentials into source code so dangerous?
• Why do secrets in source code create NHI governance problems?
• How should security teams protect source code repositories from identity abuse?
• Why do source code systems need behavioural monitoring?