An acquirer's open source policy should define four things: which license categories are acceptable, what evidence the target must provide, how long remediation may take after closing, and who can grant an exception. Written down once, it saves each deal from being argued from scratch.
Why have one before the deal
Without a policy, every finding becomes a negotiation. Engineers, lawyers and the deal team each apply their own instincts. A short written policy gives everyone the same starting point, and it lets the target see the rules early.
What to include
License tiers. Sort licenses into allow, review and deny, and say how each applies to shipped products versus hosted ones. For a worked example, see three tier license policy.
Evidence. List what the target must hand over: an SBOM, lock files, any prior audit report, and notices files for shipped products. State the format you accept.
Scope. Say whether the policy covers only the main product or also internal tools, mobile apps, firmware and container images.
Remediation windows. Set expected timelines by severity, for example before closing, within a set period after closing, or accepted with a note. Keep the numbers realistic for the team doing the work.
Exceptions. Name the role that can approve an exception and require the reason to be written down.
An example of a public policy
Some foundations publish their own rules. The Apache Software Foundation sorts third-party licenses into categories A, B and X, and says the first may be included, the second may be included under conditions, and the third must not be bundled. It lists the GPL family as category X for bundling. That is a policy for its own projects, not a rule for your deal, but it shows how a clear three bucket scheme reads. See the ASF categories explained.
What a policy cannot do
It cannot decide legal questions. Whether a particular use complies with a particular license is a matter for counsel. The policy only sets the process and the default stance.
Keep it short
Two pages that people follow beat twenty that they skip. Review it after the first few deals and trim anything nobody used.
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 pull request gate demo and watch how a rule blocks or allows a change. Imagine the rule being a license tier.
Click through it at your own pace, or open it full screen.
Quick check
Who should own the policy?
Usually a joint owner: someone from legal and someone from engineering or security, so rules are both enforceable and practical.
Should the policy differ for SaaS and shipped software?
Yes, in most cases. How a license applies often depends on whether code is distributed, so tiers usually differ by delivery model.
Sources
Last reviewed: 19 October 2026.
