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¶

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.

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: Initial. Developers add open source freely with no policy or inventory. Licenses are unexamined. End-of-life is discovered by accident. No one owns open-source strategy.

Level 2: Managed. A basic policy and approved-license list exist. Some scanning happens, often manually or late. An inventory is maintained for major systems. Contribution is ad hoc.

Level 3: Defined. An OSPO or equivalent owns strategy, policy, and tooling. License and vulnerability scanning is automated in pipelines, and attribution is generated automatically. SBOMs are maintained. Contribution has a clear process. End-of-life is tracked and migrations are planned. Government teams publish by default.

Level 4: Optimizing. Open source is a managed strategic asset. Compliance is fully automated and non-compliant components cannot reach production. The organization invests deliberately in critical upstream projects, contributes routinely, and stewards its own well-run projects. Dependency currency and end-of-life are continuously managed, and openness is 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