10.3 Procurement, open source, and licensing

Overview and motivation

Nearly every modern software system is mostly assembled from components someone else wrote. Open-source software forms the foundation of operating systems, languages, frameworks, databases, and cloud infrastructure. It enters the enterprise two ways: through deliberate procurement, and through casual import statements by individual developers. This chapter is about doing that consumption (and, where it fits, contribution) deliberately. That means a strategy, license compliance, an understanding of obligations and copyleft risk, and a plan for the inevitable end-of-life of the components you depend on.

For large teams the stakes are legal, operational, and strategic all at once. Legally, open-source licenses are enforceable contracts with real obligations. Getting copyleft (licensing that can require derivative works to be shared under the same terms) wrong can, in the worst case, compel disclosure of proprietary source or trigger litigation. License violations can even block an acquisition or a public offering during due diligence. Operationally, unmanaged dependencies rot: components go unmaintained, accumulate vulnerabilities, and reach end of life while still buried deep in production. Strategically, open source is more than a cost-saving input. It is a way to avoid lock-in, attract talent, and shape the ecosystems you depend on, advantages you only capture if you engage on purpose.

Government has an added dimension. Many jurisdictions now have explicit policies favoring open source, open standards, and code sharing between agencies. These are often expressed as “public money, public code”: the principle that software funded by taxpayers should, by default, be available to the public. So public-sector engineers must navigate both license compliance and active mandates to prefer, publish, and reuse open source. This chapter aims to make all of it manageable at scale.

Key principles

Open source is a supply chain, not free stuff. Treat consumed components with the same rigor as any critical supplier.
Licenses are obligations, not permissions to ignore. Every dependency carries terms; know them before you ship.
Copyleft is a design constraint, not a taboo. Copyleft licenses are usable and valuable; they just require you to understand how you combine and distribute software.
Consume deliberately, contribute strategically. Decide what to bring in and, where it serves you, invest in upstreaming rather than forking.
Inventory everything. You cannot comply with, secure, or update what you cannot see; an SBOM (software bill of materials, a complete inventory of the components in your software) is table stakes.
Plan for end of life from the start. Every dependency will one day be unmaintained; know your exit before you are forced into one.
In government, default to open. Prefer open standards and open source, and publish public-money code unless there is a specific reason not to.

Recommendations

Set an open-source strategy and consumption policy

Publish a clear policy for how developers may bring open source into the organization: which licenses are pre-approved, which require review, and which are prohibited for your use cases. Provide a fast, low-friction approval path. A policy slower than copying code will simply be ignored. Distinguish contexts, because the same license behaves differently when a component is used internally as a service, embedded in a distributed product, or linked into a proprietary application. Make the easy path the compliant path: a curated internal repository of vetted components, automated scanning in the pipeline, and clear guidance developers can follow without calling a lawyer for routine cases.

Manage license compliance, obligations, and copyleft risk

Get to know the families of licenses and their obligations. Permissive licenses (such as MIT, BSD, and Apache 2.0) mainly require attribution and notice preservation; Apache 2.0 adds an explicit patent grant. Weak copyleft (such as LGPL and MPL) requires you to share modifications to the covered files but generally lets you combine with proprietary code. Strong copyleft (such as GPL) can require that the whole distributed work be offered under the same terms. Network copyleft (AGPL) extends that obligation to software offered over a network, not just distributed as binaries. The obligations that matter most turn on two things: whether you distribute the software, and how tightly you combine components. Automate compliance: scan dependencies for licenses, generate and ship the required attribution and notice files, and gate the build on policy so a prohibited license cannot silently enter production.

Establish an Open Source Program Office (OSPO)

If you consume open source at scale, create a focal point, an OSPO, that owns open-source strategy, policy, compliance tooling, contribution governance, and community relationships. The OSPO curbs the chaos of every team making its own decisions. It provides expertise that individual teams cannot maintain. And it captures strategic value: deciding which projects to invest in, when to contribute upstream, and how to release your own open-source projects well. Even a small OSPO (sometimes one person plus a cross-functional working group) dramatically improves consistency and reduces legal risk compared with a free-for-all.

Govern contribution and, where fitting, publication

Decide deliberately when to contribute back. Upstreaming fixes and features to projects you depend on reduces your maintenance burden, because you stop carrying private patches. It also builds goodwill and influence, and strengthens components critical to you. Give developers a clear, fast process for approved contributions, including how intellectual property and contributor agreements are handled. When you release your own open-source projects, do it properly: choose an appropriate license, document governance, and commit to stewardship. An abandoned project harms your reputation more than no project.

Meet government open-source and “public money, public code” mandates

Public-sector teams should treat openness as the default. Prefer open standards to avoid lock-in and to work across agencies and vendors. Publish source code developed with public funds openly, unless a specific, documented exemption applies: for security-sensitive components, third-party rights, or privacy concerns. Reuse before you build: check whether another agency has already released suitable code. Bake these expectations into procurement, so vendors deliver open, reusable, well-documented code with the government keeping appropriate rights, rather than proprietary black boxes the agency cannot maintain or share.

Manage dependencies and end-of-life software

Maintain a live inventory (SBOM) of every component and its version, license, and maintenance status. Keep dependencies reasonably current. Small, frequent updates are far cheaper and safer than rare, giant leaps. Watch upstream projects for end-of-life announcements and security-support windows, and plan migrations before support ends, not after a vulnerability forces a scramble. For critical components at risk of abandonment, decide in advance whether you will fund the maintainer, contribute maintenance yourself, fork, or replace. Track end-of-life for commercial and open-source software alike, and hold running out of support to the same standard as any other operational risk.

Trade-offs: pros and cons

Choice	Pros	Cons
Consume open source freely	Fast delivery; huge leverage; no license fees	License, security, and maintenance obligations you now own
Strict license allow-list	Low legal risk; predictable	Slows teams; may exclude genuinely useful components
Permissive licenses only	Minimal obligations; easy to combine	Forgoes valuable copyleft projects; less reciprocity
Accept copyleft where suitable	Access to strong ecosystems; reciprocity benefits	Requires care in combination and distribution
Contribute upstream	Less private-patch burden; influence; goodwill	Ongoing effort; IP and process overhead
Build proprietary instead	Full control; no external obligations	High cost; reinvents commodity; you maintain it forever
Government publish-by-default	Transparency; reuse; avoids lock-in	Publication effort; security review; sustained stewardship

The central tension is between developer velocity and control. Lock everything behind heavy review, and developers route around the policy. That creates unmanaged shadow dependencies, which are worse than a permissive-but-visible approach. Leave it entirely uncontrolled, and you accumulate legal and security debt invisibly. The resolution is automation and curation: make the compliant path the fastest path, through pre-vetted components, pipeline scanning, and clear defaults, so you get control without friction. On copyleft, the trade-off is not “risky versus safe” but “understood versus not.” Copyleft is entirely usable once you know how you combine and distribute.

Questions to discuss with your team

What is your explicit rule for strong and network copyleft across internal, distributed, and network-served contexts? Copyleft is a design constraint, not a taboo, and the obligations turn on two things: whether you distribute the software and how tightly you combine components. GPL in an internal tool behaves very differently from GPL linked into a product you ship, and AGPL extends disclosure duties to software you merely offer over a network, which changes your build-versus-adopt calculus for anything you run as a service. Write the rule down per context, so a developer knows without calling a lawyer that (for example) permissive is pre-approved everywhere, strong copyleft is fine internally but blocked from the shipped product, and AGPL needs review before it touches a networked service. Bring evidence: scan your current dependency tree and find where copyleft components already sit relative to your distribution boundary. Then gate the build on that policy, because a rule no scanner enforces is a rule developers will accidentally break.
Do you need an Open Source Program Office, and who owns license policy, scanning, and contribution decisions today? If the honest answer is “no one” or “each team decides,” you are running a free-for-all that accumulates legal and security debt invisibly. An OSPO, even one person plus a cross-functional working group, curbs that chaos and captures strategic value: which upstream projects to invest in, when to contribute, and how to release your own projects well. Bring evidence to the meeting: can anyone produce the current approved-license list, the SBOM, and the name of the person who would field a copyleft question during acquisition due diligence? The answer should assign clear ownership and make the compliant path the fastest path, through pre-vetted components and pipeline scanning, so developers get control without friction. A policy slower than copying code will simply be ignored.
Which dependencies would hurt most if abandoned tomorrow, and what is your pre-decided response for each? Every dependency reaches end of life eventually, and the expensive version of that event is discovering a core component lost support months ago, only when a vulnerability forces attention. For your critical components at risk of abandonment, decide in advance whether you will fund the maintainer, contribute maintenance yourself, fork, or replace. Bring evidence: from your SBOM, list the components whose failure would stop a revenue or mission-critical service, and note each one’s maintenance status and security-support window. The answer should turn end-of-life from a surprise into a tracked operational risk with a planned migration, held to the same standard as any other risk. Keeping dependencies current in small, frequent steps is far cheaper than the rare, giant, forced leap.
Can you produce a complete, current SBOM that reaches all the way down your transitive dependency tree, and how quickly? When a headline vulnerability lands in a widely used library, the first question leadership asks is “are we exposed, and where?” A team that cannot answer within hours is already behind, because the real risk usually hides several layers deep in dependencies nobody chose on purpose. The competing consideration is cost and noise: full transitive inventory across many services generates a large, churning list, and over-alerting trains people to ignore it, so you have to decide what depth and what severity actually trigger action. Bring evidence to the discussion: try to generate a fresh SBOM for one production service right now, count how many components are direct versus transitive, and time how long it took. For an enterprise or government body, tie this to a concrete incident-response target and to any regulatory duty to disclose affected components, because a mandate to report exposure you cannot enumerate is a mandate you will breach.
When is a critical dependency worth funding, contributing to, or stewarding, rather than treating as free? Most organizations consume open source as if it were a utility, then are shocked when a component underpinning a revenue service turns out to be one unpaid volunteer. Deciding deliberately to fund a maintainer, upstream fixes, or release and steward your own project converts a fragile free input into a durable, influenced one, and it stops your engineers from carrying private patches through every upgrade. The tension is that contribution and stewardship cost real, ongoing engineering time and carry intellectual-property and process overhead, so you cannot do it for everything. Bring evidence: from your SBOM, mark the handful of components whose failure would stop a mission-critical service, and note each one’s maintainer count, funding, and how many private patches you already carry against it. For a large or public organization, weigh the reputational cost of an abandoned open-source release you published with fanfare, and, in government, treat sustained stewardship of published public-money code as part of the delivery, not an optional extra.
Does your procurement actually deliver open, reusable, well-documented code with the rights you need, or proprietary black boxes you cannot maintain or exit? Contracts written without open-source expertise routinely hand a vendor control you will regret: closed formats, no right to publish or modify, and dependencies the agency cannot patch when the vendor moves on. Getting this right early is far cheaper than discovering at renewal that you cannot leave. The competing considerations are speed and vendor choice: demanding open deliverables and portability can narrow the field and slow an award, and some genuinely useful suppliers resist it. Bring evidence: pull two recent contracts and check whether they specify license terms, source-code delivery, documentation standards, SBOM provision, and the rights the organization retains. For enterprise procurement, connect this to lock-in and total-cost analysis; for government, connect it to open-by-default and “public money, public code” mandates, and to the documented-exemption process that lets you close only the security-sensitive parts rather than the whole system.

Sector lens

Startup. You assemble almost everything from open source and have no lawyer, so keep the rule to one page: permissive licenses like MIT and Apache 2.0 are pre-approved, strong copyleft is fine for internal tooling but blocked from the shipped product, and anything odd gets a quick founder review. Add a license and vulnerability scan to the pipeline and keep an SBOM from day one, because the cheapest moment to get this right is before an acquirer’s due diligence combs your dependency tree. Do not ban copyleft out of fear; understand it, and move on.

Small business. With no open-source specialist and a tight budget, lean on tooling rather than headcount: a scanner in the build and a short approved-license list do most of the work a person would. Frame consumption as buy-versus-build honestly, since reinventing a well-maintained open component is usually the expensive choice, but so is depending on one you never inventory. Keep a simple record of what you use and under what license, so a customer security questionnaire or a vulnerability alert does not become a scramble.

Enterprise. At scale the problem is consistency across many teams, so stand up an OSPO to own policy, automated scanning, attribution generation, and contribution governance, and make the compliant path the fastest path through curated, pre-vetted components. Enforce copyleft rules per context in the pipeline, maintain SBOMs across services, and manage dependency currency and end-of-life as tracked operational risk. Treat open source as supply-chain management for the majority of your codebase, with audit-ready evidence for acquisition due diligence.

Government. Openness is often mandated, not optional, so default to open standards and publish public-money code unless a documented exemption applies for security, third-party rights, or privacy. Reuse before building by checking a cross-government catalog, and bake open, reusable, well-documented deliverables and retained rights into procurement so you receive maintainable code rather than proprietary black boxes. Hold published code to real stewardship, and keep the exemption process narrow and transparent so it closes only what it must.

Examples

Startup. A four-person startup building a mobile app assembles almost everything from open source and has no lawyer on staff. Instead of banning copyleft out of fear, the founders write a one-page policy: permissive licenses like MIT and Apache 2.0 are pre-approved, strong copyleft such as GPL is fine for internal tooling but blocked from the shipped app to avoid disclosure duties, and anything unusual gets a quick founder review. They add a license and vulnerability scan to the pipeline so a prohibited license cannot slip into a release, keep an SBOM from day one, and upstream a small fix to a critical library so they stop carrying a private patch through every upgrade. Getting this right early also spares them a painful surprise when an acquirer’s due diligence eventually combs the dependency tree.

Enterprise. A software vendor that ships a distributed product runs an OSPO. The OSPO maintains an approved-license list, an internal curated component repository, and automated license and vulnerability scanning in every pipeline. When a developer pulls in a new dependency, the pipeline checks its license against policy, generates the attribution notices that ship with the product, and flags anything requiring review. Strong-copyleft components are allowed for internal tooling but blocked from the distributed product, to avoid disclosure obligations. The company upstreams fixes to a few critical dependencies. That eliminated a backlog of private patches its engineers used to carry across every upgrade.

Government. A national digital service operates under a “public money, public code” policy. New services are built on open standards, developed in the open on a public code repository by default, and reused across agencies. Its procurement templates require vendors to deliver open, well-documented, reusable code, with the government keeping rights to publish and modify. Before starting a new component, teams search a cross-government catalog for existing reusable code. Security-sensitive modules are exempted from publication through a documented process, rather than by making the whole system closed.

Business case: motivations, ROI, and TCO

Managing open source well is the difference between capturing its enormous leverage and paying for its hidden costs. Open source lets a large organization stand on a foundation it could never afford to build. But the total cost of ownership includes compliance, security patching, and eventual migration, costs that arrive whether or not you plan for them. Deliberate management converts unpredictable, expensive crises into small, steady, planned costs. Those crises include a copyleft violation found during acquisition due diligence, an emergency migration off an abandoned component, or a vulnerability in a dependency nobody knew was there.

The adoption cost is modest next to the exposure: an OSPO or working group, scanning tooling, and the discipline of keeping an inventory. The cost of not adopting shows up as legal liability, failed due diligence, security incidents traced to unpatched dependencies, and the compounding expense of deferred upgrades that eventually force painful big-bang migrations. When you make the case to leadership, frame open-source management as supply-chain management for the majority of your codebase. Note the strategic upside too: avoided lock-in, faster delivery, talent attraction, and influence over the ecosystems you depend on. In government, add the mandate dimension. Openness is often required, not optional, and doing it well avoids both non-compliance and duplicated public spending.

Anti-patterns and pitfalls

Copy-paste licensing. Developers pulling in components with no license check, discovering obligations only at audit or acquisition.
No inventory. Being unable to answer “what are we using and under what license?” when a vulnerability or license question breaks.
Copyleft panic. Banning all copyleft out of fear rather than understanding, forgoing valuable ecosystems.
The abandoned open-source release. Publishing a project with fanfare and then never maintaining it, damaging reputation.
Ignoring transitive dependencies. Vetting direct dependencies while the real risk hides several layers deep.
End-of-life surprise. Discovering a core component lost support months ago, only when a vulnerability forces attention.
Policy slower than copying. A compliance process so heavy that developers route around it, creating invisible shadow dependencies.
Government black boxes. Procuring proprietary systems the agency cannot maintain, share, or exit, in violation of open-by-default principles.

Maturity model

Level 1: Initiate. Developers add open source freely with no policy or inventory. Licenses are unexamined and copyleft obligations are unknown. End-of-life is discovered by accident, usually when a vulnerability forces attention. No one owns open-source strategy.

Level 2: Develop. A basic policy and approved-license list exist, and some teams follow them. Scanning happens, but often manually, late, or only on a few projects. An inventory is kept for major systems while transitive dependencies go unmapped. Contribution and end-of-life handling are ad hoc and inconsistent between teams.

Level 3: Standardize. An OSPO or equivalent owns strategy, policy, and tooling org-wide. License and vulnerability scanning is automated in every pipeline, attribution and notice files are generated automatically, and the build is gated so a prohibited license cannot enter. SBOMs are maintained down the transitive tree, contribution follows a documented process, end-of-life is tracked with planned migrations, and government teams publish by default.

Level 4: Manage. The program is measured and controlled against baselines. You track policy-scan coverage across services, mean time to patch a disclosed dependency vulnerability, the share of components inside their security-support window, license-violation escape rate, dependency-currency lag, and the count of private patches carried upstream. Copyleft placement relative to the distribution boundary is monitored, and metrics against targets drive each go or no-go decision rather than opinion.

Level 5: Orchestrate. Open source is a continuously improved strategic asset integrated across the organization. Compliance is fully automated and non-compliant components cannot reach production. You invest deliberately in critical upstream projects, contribute routinely, and steward your own well-run projects. Dependency currency and end-of-life are managed adaptively as risk and metrics shift, and openness becomes a genuine competitive and civic advantage.

Ideas for discussion

Where is the right line between a fast permissive default and the control needed to avoid legal and security debt?
When should an organization fund or maintain a critical upstream dependency rather than treat it as free?
How do you decide which of your own components are worth releasing and stewarding as open source?
For government, what is a defensible process for exempting components from publish-by-default without eroding the principle?
How deep into transitive dependencies must license and security review realistically go?
Does network copyleft (AGPL) change your build-versus-adopt calculus for software you offer as a service?

Key takeaways

Open source is the majority of most codebases and must be managed as a supply chain, not treated as free and consequence-free.
Licenses carry real obligations; understand permissive, weak-copyleft, strong-copyleft, and network-copyleft families and how distribution and combination trigger duties.
Make the compliant path the fastest path through curation, automated scanning, and clear defaults, or developers will route around policy.
Stand up an OSPO to own strategy, compliance, contribution, and stewardship at scale.
Maintain an SBOM, keep dependencies current in small steps, and plan for end of life before it forces a crisis.
In government, default to open standards and publish public-money code, reusing before building.

References and further reading

Heather Meeker, Open (Source) for Business and Open Source for Business
Van Lindberg, Intellectual Property and Open Source
The Linux Foundation and TODO Group, OSPO guides and Open Source Program Office resources
OpenChain (ISO/IEC 5230), Open Source License Compliance
Software Package Data Exchange (SPDX, ISO/IEC 5962) specification
CycloneDX SBOM specification
Free Software Foundation, GNU General Public License and GPL FAQ
Open Source Initiative, The Open Source Definition and approved license list
Free Software Foundation Europe, Public Money, Public Code
U.S. Federal Source Code Policy and Code.gov guidance
UK Government, Technology Code of Practice and open-standards principles