Licenses on shipped code matter most, since most obligations are triggered by distributing software. A build tool that never ends up in your product usually raises fewer questions. But check what the tool adds to the output, because some tools embed runtime code or generated files that carry their own terms.
Why the split exists
Many open source licenses attach conditions to copying and distributing the software. If a tool only runs on your build machine and nothing from it is in the artifact, there may be no distribution of that tool.
The Apache Software Foundation says in its licensing policy that using a GPL licensed tool during the build is acceptable if it does not affect the licensing of the project. That is a statement about its own projects, but the logic is a useful guide.
The cases to separate
| Dependency type | Typical question |
|---|---|
| Runtime library linked into the product | Which license, and how is it shipped? |
| Dev dependency, tests and linters | Does any of it appear in the release? |
| Compiler or code generator | Does its output include its own runtime code? |
| Container base image | Is the full image shipped to customers? |
| Plugin or script run in CI only | Does it touch the produced artifact? |
Where build tools leak into output
- Code generators that emit helper files with license headers
- Bundlers that inline library code into a single file
- Compilers with runtime libraries linked into binaries; some of those carry special exceptions
- Docker multi stage builds where an earlier stage is copied forward
The bundler case is worth attention in web apps. A minified bundle can contain many libraries, so their notices must still be handled.
How to check
- Separate dev and runtime dependencies in your manifest.
- Generate an SBOM of the built artifact, not just the source tree.
- Compare the artifact list to the dependency list and note the gaps.
- Mark each tool as shipped or not shipped in your inventory.
- Ask whether any of the tools provide an exception for their output.
In diligence
Buyers often ask to see the dev and runtime split. Having it ready shortens the discussion and lets you focus the review on shipped components. For the internal use versus distribution question, see when copyleft applies.
Safeguard supports policies, gates and guardrails, so a team can decide which findings block a pull request and which only warn. A free scan is available if you want to see your own dependency list first.
Try it yourself
Open the inventory and sort components in your mind into shipped and not shipped. See how a single list can hide that distinction.
Click through it at your own pace, or open it full screen.
Quick check
Can I ignore dev dependencies entirely?
Not entirely. Security issues can reach your pipeline through them. For licensing, the question is whether anything ends up in the release.
Is hosted software treated like shipped software?
Often differently, and some licenses address network use directly. See the AGPL discussion in the linked posts, and ask counsel.
Sources
Last reviewed: 19 October 2026.
