Keep a register of customer specific open source restrictions, and link each entry to the products and versions that customer receives. Then check your component inventory against it at release time. A clause that lives only in a signed PDF will be broken by accident.
How the restriction shows up
Enterprise buyers and regulated customers sometimes write open source terms into the master agreement or a security addendum. Typical wording bans certain license families in delivered software, asks for a list of components, or requires approval before a copyleft component is added. The details vary by contract, so read yours rather than assuming a standard form.
The trouble is where the clause lives. Legal signs it, sales files it, and engineering never sees it. Months later a developer adds a library that your company policy allows, and the delivery to that customer is now out of line with its contract. Nobody did anything wrong by internal policy. This is general guidance, not legal advice.
What a register contains
| Field | Example content |
|---|---|
| Customer and contract reference | Name, agreement, date, clause number |
| Restriction | Plain statement, such as no AGPL in delivered code |
| Applies to | Products, versions, deployment type |
| Approval path | Who can approve an exception for this customer |
| Review date | When the clause or the delivery is next checked |
| Owner | One named person in legal or contracts |
Keep it short. A register that takes an hour to read will not be read.
Four steps to wire it in
- Collect. Ask legal for every active customer clause that mentions open source, licenses, or third party components. Do this once, then add an intake step so new contracts reach the register.
- Map. Link each entry to the products and release lines that customer actually runs. Many restrictions apply to one product, not the whole company.
- Check. Run the restriction as a policy against the SBOM of each delivered version. The rule is the same kind of rule as your company tiers, scoped to one customer's delivery.
- Decide. When a component conflicts, the options are replace it, ask the customer for an exception, or deliver a different build to that customer. Record the choice.
Our post on replying when a customer asks about GPL and AGPL covers the conversation side. Once you have a register you can answer from facts.
Where it breaks
Dedicated builds per customer are the hardest case, because inventories drift. Keep the SBOM for each customer's build, not just the main branch. Also watch updates. A dependency update can swap a transitive component's license, so re-run the check on every release, and on dependency update pull requests for the products involved. See can a dependency update change the license.
Do not put the restriction into a developer's head as a rule of thumb. Put it in a check, so the answer is the same on a Friday evening as on a Monday morning.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a gate returns a clear pass or block with a reason, which is the output a customer specific rule should give.
Safeguard's SBOM and dependency scanning builds a component inventory with license data, and policies and gates can block a pull request on a license rule you define. You can try a free scan at gold.safeguard.sh.
Quick check
Who should own the register?
A named person in legal or contracts, with engineering responsible for the checks. One owner avoids the clause going stale.
Does a customer restriction change our company policy?
Not necessarily. Keep company policy as the baseline and add the customer rule only to the products and versions that customer receives.
Last reviewed: 19 October 2026.
