The Build Passes, but One Dependency Is AGPL: When Is This a Compliance Project?
Separate an AGPL package finding from the exact license expression, product use and blocked release decision before scoping open-source compliance work.
Signals to watch
- A named package and version have an exact SPDX license expression and dependency path
- The product team can describe modification, conveyance and remote-network interaction separately
- A release, acquisition or supplier-review decision is blocked with an accountable owner and date
A build that passes with an Affero General Public License dependency has established a technical fact, not the scope of a compliance project. An AGPL finding becomes project-ready when a named package and version, exact license expression and product use are tied to a blocked release, acquisition or supplier decision with an owner and date. Before that, the useful work may be inventory correction rather than legal interpretation or code replacement.
This distinction matters to a software-composition-analysis vendor business-development lead reviewing authorised developer, security, procurement and open-source programme Telegram groups. “AGPL showed up in the scan” is worth reading, but a day-late response matters only if a release exception, acquisition review or supplier answer is already moving. Quoting remediation from the acronym alone can sell the wrong service and overstate what the license text says.
An illustrative fragment might read:
“Build is green now. Legal flagged one AGPL package in the backend service. Need an answer before release review.”
This is a composite example, not a customer message. It does not identify the package, version, dependency path, license expression, modification, deployed function, distribution model, users, policy or reviewer.
AGPL names a license, not a single architecture verdict
The GNU Affero General Public License version 3, or AGPLv3, is a free-software license based on GNU GPLv3. Its best-known addition is section 13. The official GNU text says that if a licensee modifies the Program, the modified version must prominently offer users who interact with it remotely through a computer network an opportunity to receive the Corresponding Source.
That sentence contains several objects that a scan result does not supply: the Program, a modified version, the users interacting with it, the network interaction and the Corresponding Source for that modified version. Other sections govern copying, modification and conveying covered works. Whether separate application code is part of a covered work is an architecture-specific and legal question, not a conclusion that a sales team should generate from “AGPL present.”
The first discipline is therefore to preserve the exact evidence. The Software Package Data Exchange (SPDX) License List entry identifies AGPL-3.0-only. AGPL-3.0-or-later is a different identifier. Under the SPDX 2.3 license-expression rules, OR denotes a license choice, AND combines requirements, and WITH attaches a named exception. Replacing a package’s recorded expression with the word “AGPL” can erase the very choice or exception that a reviewer needs.
A green build answers the wrong question
Software composition analysis (SCA) identifies components and associated evidence in source, build or artifact scans. A successful build shows that a selected set of components compiled, linked or packaged well enough for the build system. It does not prove five other facts:
- which package version is in the released artifact;
- which license files and notices belong to that version;
- whether the organisation modified the covered program;
- how that program interacts with users or other application components; or
- which legal and internal-policy conclusion the organisation accepted.
Start with the dependency path. A direct application dependency, a build-time tool, a test-only package and a service reached over a protocol do not occupy the same technical position. Record the package manager, manifest, lockfile, resolved version, artifact and scanner evidence. The dependency-lockfile evidence test explains why a repository tree is not automatically proof of the shipped artifact.
Next, separate a software bill of materials (SBOM), which inventories components, from a Vulnerability Exploitability eXchange (VEX) statement, which communicates a vulnerability assessment. Neither is a license conclusion. The SBOM and VEX comparison helps prevent a security deliverable from being mistaken for license evidence.
Four different projects can begin with the same scanner row
The commercial contribution is not another red/yellow/green score. It is a routing decision based on the deliverable that is missing.
| Failed decision object | What is actually missing | Likely project |
|---|---|---|
| Component record | Package, version, dependency path or license file is unresolved | Inventory and evidence repair |
| Internal release rule | The organisation knows the component and use, but policy has no approved treatment | Policy exception or governance review |
| License conclusion | Facts are documented, but the effect of modification, combination, conveyance or network interaction is disputed | Qualified legal interpretation |
| Release architecture | A reviewed obligation or policy decision cannot be met in the current design | Technical remediation, replacement or isolation |
Inventory repair should not be sold as legal advice. Legal interpretation should not be sold as an automated scanner feature. Technical remediation should not begin until the team knows which reviewed requirement the architecture must satisfy.
This routing also identifies the minimum next question. For an unresolved component record, ask for the resolved package and artifact. For a policy exception, ask which policy clause blocked release. For legal interpretation, provide counsel with stable technical facts rather than a screenshot. For remediation, ask which interface or distribution path must change and what acceptance test will close the issue.
The remote-network question needs an architecture record
Section 13 makes remote interaction important, but “it runs in software as a service” is still too broad. A useful architecture record names the AGPL program, whether it is modified, where it runs, who interacts with that program remotely, how it communicates with surrounding components, what is conveyed to customers and which source offer exists.
Consider two incomplete statements:
“It is only a command-line utility in the image.”
“Customers never download it; they only use our Web app.”
Neither statement closes the review. The first does not say whether the utility is modified or included in a conveyed artifact. The second does not say whether users interact remotely with a modified AGPL program. The architecture owner supplies facts; qualified counsel interprets the license for the actual facts; the release owner accepts the decision.
The strongest counterargument is that this process makes one dependency sound larger than it is. That risk is real. A package with reliable license evidence and an already approved use pattern may need only routine documentation. The project threshold is not license severity. It is a missing deliverable that blocks a dated decision.
Return to the release-review message
The illustrative message contains two useful facts: a build succeeded and someone marked a dependency for review. It becomes a qualified compliance project only after the record can answer:
- What software is it? Preserve package, version, artifact, dependency path and exact SPDX expression.
- How is it used? Separate modification, remote interaction, combination and conveyance rather than compressing them into “SaaS.”
- What is blocked? Name the release, acquisition or supplier response and the decision date.
- Which deliverable closes the block? Inventory evidence, a policy exception, legal advice or a technical change are different statements of work.
If a group fragment includes only “AGPL,” monitor for a second message naming the package or release decision. TOP Prospect can merge and rank fragments from Telegram groups the user deliberately connects and is authorised to access, while retaining source, time and original text for a person to review. It cannot inspect the private repository, decide license obligations, give legal advice, contact the writer or approve the release. The official-source routing method is useful when a forwarded scanner finding has lost its package or advisory object; the pricing page describes the product’s discovery boundary.
The release review does not need a generic warning that AGPL is “high risk.” It needs one exact component record, one documented use, one blocked decision and one missing deliverable. That is the point at which a license question becomes a compliance project.
FAQ
Does any AGPL dependency require a company to publish its entire application?
That conclusion cannot be drawn from the dependency label alone. The exact covered work, license expression, modifications, combination with other code, conveyance and remote-network use all matter. Section 13 addresses users interacting remotely with a modified version of the Program. Qualified legal review may still be needed for the specific architecture.
What is the difference between AGPL-3.0-only and AGPL-3.0-or-later?
They are different SPDX identifiers. AGPL-3.0-only names version 3 only; AGPL-3.0-or-later permits version 3 or a later version under the license’s version clause. Preserve the identifier supported by the package evidence.
Why is a successful build not enough license evidence?
A build proves that selected components compiled or packaged. It does not establish their license expressions, the shipped artifact, modification history, product architecture or the organisation’s accepted legal and policy conclusions.
What makes the finding ready for a compliance-services proposal?
The proposal is ready when it names the package and version, evidence for the license expression, the relevant product use, the decision currently blocked, the missing deliverable and the person responsible for accepting it.
Frequently asked questions
Does any AGPL dependency require a company to publish its entire application?
That conclusion cannot be drawn from the dependency label alone. The exact covered work, license expression, modifications, combination with other code, conveyance and remote-network use all matter. Section 13 addresses users interacting remotely with a modified version of the Program. Qualified legal review may still be needed for the specific architecture.
What is the difference between AGPL-3.0-only and AGPL-3.0-or-later?
They are different SPDX license identifiers. AGPL-3.0-only names version 3 only; AGPL-3.0-or-later permits the licensee to use version 3 or a later version under the license’s version clause. A scanner should preserve the identifier actually supported by the package evidence.
Why is a successful build not enough license evidence?
A build proves that selected software components compiled or packaged together. It does not establish the components’ license expressions, the shipped artifact, modification history, product architecture or the organisation’s legal and policy conclusions.
What makes the finding ready for a compliance-services proposal?
The proposal is ready when it names the package and version, evidence for the license expression, the relevant product use, the decision currently blocked, the missing deliverable and the person responsible for accepting it.
Sources and further reading
How a Signal worth attention is found
See how Top Prospect finds and organizes Signals worth checking, keeps the original Telegram context, removes duplicates, and helps you decide what to review first. You decide whether to follow up and what to do next.
