Architecture review matters because license obligations can depend on how components connect, not only on which components you use. A scan lists parts. The TODO Group guide adds a review of how open source, proprietary and third-party code interact, such as through linking or sockets.
What the guide says
In the TODO guide to using open source code, stage four of the review process is the architecture review. The compliance officer and an engineering representative analyze the interaction between open source, proprietary and third-party code, by examining an architectural diagram.
The result is an analysis of the licensing obligations that may extend from open source to proprietary or third-party components, and across open source components. The guide gives one example: a proprietary component linking to a GPL licensed component. If the compliance officer finds an issue like that, the ticket goes back to engineering for resolution.
This post describes process. Whether a given connection triggers an obligation is a legal question for your counsel.
What the diagram should show
The guide lists what the architecture diagram identifies:
- Open source components, used as is or modified.
- Proprietary components.
- Components from third-party suppliers.
- Component dependencies.
- The method of communication between components, such as TCP/IP, a Linux socket, or a function API with static or dynamic linking.
- Communication protocols.
- Other open source packages the component interacts with or depends on, especially if governed by a different license.
The communication method is the detail that scans miss. Two components can both appear in a scan result while the way they talk to each other determines whether anyone needs to look closer.
A simple review checklist
| Question | Why ask it |
|---|---|
| Is this component used as is or modified? | Modified code often carries extra duties |
| How does our code call it: linked, process call or network? | The connection type matters to legal review |
| Is it linked statically or dynamically? | Counsel will usually ask |
| Does it depend on packages with different licenses? | Mixed licenses need checking |
| Is any of it supplied by a third party? | You may need the supplier's information |
Bring the answers to legal review with the scan report. Counsel, not the engineer, interprets them.
When to do it
You do not need a full architecture review for every library. The guide describes the process for components where the earlier stages found something worth examining, and it says the phases may be adapted to your company. Reasonable triggers include a new copyleft license, a modified component, or a component embedded in a distributed product. See license review versus security review for how to run the two checks together.
Keep the diagram useful
Store the diagram next to the code and update it when the architecture changes. A diagram from three releases ago is worse than none, because it gives false comfort.
Try it yourself
Click through it at your own pace, or open it full screen. Use the component list as the starting point for the diagram.
How Safeguard fits
Safeguard provides SBOM and dependency scanning, which gives you the component and license list that an architecture review starts from. Try gold.safeguard.sh/scan. The review itself stays with your engineers and counsel.
Quick check
Does a scan replace architecture review?
No. A scan lists components and licenses. The review looks at how they connect.
Is this legal advice?
No. Ask your counsel how licenses apply to your specific architecture.
Sources
Last reviewed: 19 October 2026.
