Corresponding Source Code

What Corresponding Source Code Means in GPL Distribution

Corresponding source code is the complete, buildable source package that matches a GPL-licensed distributed work. It is meant to let recipients install, rebuild, and modify the software, so the obligation is broader than handing over a patch, a subset of files, or a conveniently reduced export.

The practical distinction matters because the GPL is about usable freedom, not symbolic disclosure. If an organisation ships binaries or a modified GPL work, the recipient must be able to reproduce the covered work from the source materials provided, including the pieces needed to compile and link it in the distributed form.

What Must Be Included

In practice, corresponding source normally includes the source files that make up the program, plus the scripts and build logic needed to turn that source into the distributed executable. It can also include interface definitions, configuration needed to build the work as shipped, and any local changes the distributor made.

The key test is whether a recipient can reasonably rebuild and modify the conveyed work. If essential build steps depend on proprietary tooling, hidden files, or undocumented repositories, the package may be incomplete even if a large amount of code has been handed over.

This is why source-code delivery often becomes an operational process, not a one-off file dump. Organisations need to know which repositories, branches, generated files, dependency pins, and build scripts belong to the distributed work, and which items are merely adjacent but not part of the deliverable.

Why It Matters for Compliance and Trust

For GPL-covered software, incomplete source delivery creates licensing exposure and can undermine downstream trust in the distributor. Recipients, customers, and auditors care less about whether a team "shared some code" and more about whether the delivered package actually supports installation, modification, and rebuild rights.

That distinction becomes especially important when source is spread across many repositories or when release engineering generates artefacts from private internal systems. The licence obligation follows the distributed work, not the convenience of the publisher's internal folder structure.

Teams also need to treat source-package accuracy as part of software provenance. If the published source does not match the shipped binary, or if it omits the files that make the release reproducible, the result is a governance problem as well as a licensing one.

How Organisations Should Handle It

The safest approach is to maintain a release process that can identify the exact source tree, build inputs, and modification history for each GPL-covered shipment. That process should be repeatable, reviewed, and owned by release engineering, legal, or open-source compliance teams rather than left to individual developers.

Where the deliverable is assembled from multiple repositories or generated components, the organisation should document what counts as corresponding source and preserve enough release metadata to reconstruct the package later. If a recipient asks for the source, the answer should be immediate and complete, not assembled ad hoc from forgotten branches.

When distribution includes code that has been patched internally, the published source should reflect those changes cleanly so recipients can study and modify the same work that was conveyed. In that sense, corresponding source code is both a licensing artefact and an operational discipline.

Risk and Threat Considerations

When organisations mishandle corresponding source code, the main risk is not just non-compliance, but incomplete or misleading disclosure of the work actually distributed. That can trigger licence disputes, delay releases, and create confusion about what was built, modified, or shipped.

Failure mechanism: Teams publish a partial source set, omit build scripts or local changes, or separate the release artefact from the source history that produced it. The recipient cannot reliably rebuild the conveyed work, and the distributor may be unable to prove that the published package matches the shipped version.

Impact: The organisation can face legal exposure, remediation work, and reputational damage, while downstream users lose confidence in the integrity and maintainability of the release.

Practitioner Guidance

What to watch for: Treat source delivery as a release control, not a file-sharing exercise. The important question is whether your process can consistently identify the exact source, build inputs, and modifications that belong to each GPL-covered release.

Governance implication: Ownership should sit with the release process, with clear checks for completeness before software is shipped. If the organisation cannot demonstrate that the published source maps to the distributed work, the compliance process is not mature enough yet.

Practitioner takeaway: For GPL releases, completeness and traceability matter more than volume. A smaller source bundle that truly corresponds to the distributed work is better than a larger one that cannot be rebuilt or verified.

Related resources from NHI Mgmt Group

• What breaks when organisations cannot produce corresponding source code for GPL-licensed software?
• 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?