Almost every company that develops software uses open source components, often in quantities nobody has ever counted. Many also have developers who fix bugs in external projects or would like to publish internal tools. Without rules, each of these activities is handled case by case, with inconsistent results: one team publishes freely, another asks the legal department for permission for a two-line fix. An internal policy and, in larger organisations, an Open Source Program Office make these activities predictable.
The three activities to regulate
An effective policy distinguishes three situations, because the risks differ.
Using open source components
This is the most frequent activity and the one with the most concrete risk. The questions to cover:
- which licenses are allowed without approval, which require review and which are excluded for certain kinds of product;
- how the use of a component is recorded, for example in an inventory or an automatically generated SBOM;
- how security updates to dependencies are handled.
A practical approach is a traffic-light table:
| Category | Examples | Rule |
|---|---|---|
| Green | MIT, BSD, Apache 2.0 | Allowed, honouring attribution obligations |
| Amber | LGPL, MPL, EPL | Allowed after checking how they are integrated |
| Red | GPL and AGPL in closed distributed products, source-available licenses | Require explicit approval |
Contributing to external projects
Here the main risk is unintentionally giving away company rights or disclosing confidential information. The policy should state:
- whether employees may contribute during working hours and with which account;
- who may sign corporate CLAs on the company's behalf;
- which contributions require prior review, for example those touching patented technology or trade secrets;
- that small fixes need no approval, so as not to discourage contributors.
Publishing your own projects
Making an internal tool public is a decision involving several functions. Before publication, specific checks are needed:
- code clean-up: no passwords, keys, internal addresses or customer names, including in the repository history;
- dependency review and compatibility of their licenses with the chosen one;
- choice of license consistent with the goals;
- basic files: README, license,
CONTRIBUTING.md,SECURITY.md, code of conduct; - ownership: who will maintain the project and with how much time.
The fifth point is the most neglected. Publishing a project and abandoning it after six months damages the company's reputation more than not publishing it at all.
What an OSPO is
An Open Source Program Office is a function, sometimes a single person, sometimes a small team, that coordinates everything to do with open source in the company. Typical tasks are:
- writing and updating the policy;
- acting as the point of contact between developers, legal and security;
- maintaining the inventory of components in use;
- approving borderline cases quickly;
- deciding which external projects to support with contributions or funding;
- training teams on licensing and good practice.
A small company does not need an office: naming a reference person and a lightweight process is enough. What matters is that questions have someone to go to and get an answer within a reasonable time, and that decisions are recorded in a single place, so that similar cases later can be settled without starting from scratch.
Frequent policy mistakes
- Banning everything out of caution: developers work around the rules and the company loses visibility of what it uses.
- Slow approvals: if it takes three weeks to approve a library, nobody will ask.
- Ignoring transitive dependencies: an approved library may pull in dozens of others with different licenses.
- Treating contributions purely as a risk: contributing to critical dependencies reduces the cost of maintaining internal patches.
In my work, the policy that works best is almost always short, with concrete examples and an automated check in the pipeline that does the work instead of people.
In short
- A company policy must regulate use, contributions and publication separately.
- A traffic-light license table simplifies day-to-day decisions.
- Before publishing you need code clean-up, a dependency review and an owner.
- An OSPO, or a reference person, coordinates policy, inventory and approvals.
- Rules that are too strict or slow get bypassed: better a few clear, automated rules.
