Governing use in an organisation.
WHY ONE IS NEEDED
Decisions made individually produce inconsistent obligations and unknown exposure.
WHAT A POLICY SHOULD COVER
Which licences are permitted, restricted or prohibited How components are approved How the inventory is maintained Obligations when distributing Vulnerability management Contribution by employees Release of the organisation's own code
WHAT TO ESTABLISH ABOUT APPROVAL
What requires it, and who gives it.
WHY NOT EVERYTHING
Approval for every component is impractical and it is bypassed.
WHAT TO PREFER
Pre-approved licences for routine use, approval for anything else.
WHAT TO PROHIBIT
Licences incompatible with your distribution model.
WHAT TO ESTABLISH
That the policy reflects how you actually distribute software.
WHY
Internal-only use carries far fewer obligations than distribution.
WHAT TO PROVIDE
Guidance developers can follow without consulting anyone.
WHY
Policies requiring consultation for routine decisions are ignored.
WHAT TO AUTOMATE
Inventory generation Licence detection Vulnerability scanning
WHY
Manual compliance does not scale and it fails silently.
WHAT TO ESTABLISH
Who owns the policy and reviews it.
WHAT TO TRAIN
Developers, on the practical rules.
WHY
Most violations are unintentional.
WHAT TO REVIEW
Compliance, periodically.
WHAT TO PREPARE FOR
Customer and buyer requests for a component list.
WHY
They are increasingly routine.
