Open Compute Licensing: A Market Economy for Public-Goods Software

Open source won because it was useful before it was monetizable.

That is also the problem.

The modern software economy runs on public code: Linux, Kubernetes, PostgreSQL, LLVM, Python, OpenSSL, Git, Docker, SQLite, Redis-like infrastructure, language package ecosystems, build tools, test frameworks, observability stacks, schedulers, compilers, shells, and thousands of libraries that most users never see. These projects are not side dishes. They are capital goods. They increase the productive capacity of everyone who builds on top of them.

Yet the market does not pay them like capital goods.

The usual open-source funding model is indirect. Large companies benefit from the shared infrastructure, so they allocate engineers. Foundations coordinate the legible projects. Some maintainers get grants, contracts, sponsorships, security work, or reputation. A few companies build a commercial layer around the public core and sell hosting, support, compliance, enterprise features, or managed cloud.

This works well enough for mature infrastructure. It works badly for venture-style search.

A small team can write public software that would be valuable if widely deployed, but there is no good market object for financing that search. If the team keeps the software proprietary, it can sell SaaS. If it releases the software openly, it may become infrastructure without becoming a business. If it uses open-core, it must decide which features to withhold. If it sells hosting, it must become an operator even if its real talent is writing the underlying software.

Open source created public goods. It did not create a market economy for creating public goods.

Open Compute Licensing is a proposal to fix that.

Free software, open source, and the pragmatic tradition

This proposal should not pretend that nothing changes.

GNU and the Free Software Foundation framed software freedom as a matter of user liberty, not price. The GNU definition says users should be free to run, copy, distribute, study, change, and improve software. It explicitly distinguishes "free speech" from "free beer."¹

The open-source movement took a different route. It kept much of the practical machinery, but made the case in terms that companies could adopt: reliability, collaboration, development velocity, security, standards, and commercial usefulness. The Open Source Initiative was founded by Eric Raymond and Bruce Perens in February 1998, and one of its early tasks was to explain and protect the "open source" label.²

That pragmatic move mattered. It made free software legible to industry.

But pragmatism cuts both ways.

The Open Source Definition says an open-source license cannot discriminate against people, groups, or fields of endeavor, including business use.³ A license that requires commercial value sharing after a revenue threshold may not be "open source" under the OSI definition. That is fine. We should not fight a terminology war by mislabeling the instrument.

Call it public-goods software.

The source is public. Small users, hobbyists, researchers, students, internal experiments, and incidental commercial users can run it without asking permission. The project can be forked, studied, modified, inspected, and improved. But once the software becomes part of a real commercial value chain, the authors have a claim on a small part of the value they helped create.

Not rent for copying.

Not a royalty on curiosity.

A value-capture claim when public software becomes a production input to a paid service.

That is the pragmatic update.

The current model is corporate mutual aid

Open source today is partly a commons and partly corporate mutual aid.

Google needs Linux. Apple needs open infrastructure. Korean electronics firms need open infrastructure. Banks, automakers, defense contractors, game studios, AI labs, ecommerce firms, and cloud providers all need it. Each company could try to own more of the stack, but it is usually cheaper and better to contribute to shared capital goods than to duplicate everything.

So the system becomes a loose cooperative. Large firms assign employees. Foundations provide governance. Critical projects get sponsorships. Mature projects become legible enough for committees, grants, security audits, and corporate roadmaps.

The Linux Foundation and related open-source organizations are good efforts. They perform real coordination work. But they were built in an earlier deployment regime, when the center of software gravity was not yet a small number of hyperscale cloud runtimes. They are excellent at stewarding known infrastructure. They are less naturally suited to funding unknown public software before it is legible.

The Linux Foundation's own 2024 open-source funding research is revealing: surveyed organizations reported $162 million in financial contributions, with 57 percent going to contractors, 37 percent to foundations and projects or communities, 4 percent to maintainers, and 1 percent to bounties.⁴ That is not a criticism. It is a map of the current system. Money reaches things that already have categories.

Venture-style public software search does not have a category.

The result is predictable. Open source gets funded when it is already important, when a company directly needs it, when a foundation can govern it, or when a startup wraps it in a service. But new public goods remain hard to finance because their upside leaks into the market before it accumulates on any balance sheet.

The cloud changed the enforcement surface

Twenty years ago, software monetization mostly meant selling licenses, support, hardware bundles, or enterprise deployments.

Today, much of the money flows through cloud bills.

The cloud is no longer a diffuse commodity hosting market. It is concentrated, metered, and legible. Synergy Research Group estimated that Q1 2026 cloud infrastructure service revenues reached $128.6 billion, with trailing twelve-month revenues of $455 billion. In that same quarter, AWS, Microsoft, and Google held 28 percent, 21 percent, and 14 percent of the worldwide cloud infrastructure services market respectively.⁵ In public cloud specifically, Synergy estimated that the top three providers accounted for 67 percent of the market.⁵

This matters because the cloud provider is already the payment rail.

A cloud provider meters CPU, memory, storage, network traffic, database usage, queues, function calls, logs, GPUs, load balancers, and managed services. It already produces the invoice that the customer pays. It already knows which customer is running which deployment primitives. It already sells the hardware, energy, networking, orchestration, and operational abstraction.

The proposal is simple: add public software value capture to that bill.

The cloud provider is not the only beneficiary of public software. A video game studio, SaaS company, bank, manufacturer, or ecommerce firm may also use public software to sell a service. But the cloud provider is the most legible place to begin because it sits at the billing boundary for a large share of commercial runtime.

The payer is the commercial service operator.

The cloud provider is the collection rail.

The Open Compute Guild is the accounting layer.

The Open Compute License

The Open Compute License would work like this.

The code is public. Anyone can inspect it, fork it, modify it, learn from it, and run it below the commercial threshold. Small users do not pay. Hobby projects do not pay. Internal experiments do not pay. A local business running a website does not become a compliance target because a JavaScript package appears somewhere in its stack.

The trigger is a real commercial value flow.

A covered deployment begins when the software is used as a production input to sell a commercial digital service above a threshold. The threshold should be high enough to avoid taxing incidental use. Ten million dollars of relevant service revenue is a useful starting point, but the exact number matters less than the principle: do not meter the car salesman because his website uses npm. Meter the service business whose runtime is materially built from public software.

The fee should be a percentage, not a fixed package price.

A fixed per-package fee would recreate the wrong incentives. If a deployment uses 200 packages, the customer should not pay 200 independent tolls. That would punish reuse and create compliance chaos. Instead, each covered Deployment Box pays a value-capture pool. The pool is then allocated among the public software that materially contributes to that runtime.

For example: a customer pays a $1,000 cloud bill. The cloud provider keeps $900 for infrastructure, energy, networking, operations, margin, and its own services. A $100 value-capture pool flows through the Open Compute Guild to the projects whose software is materially present in the Deployment Box. The numbers are illustrative, not sacred. The structure is the point.

This is not a royalty on source code.

It is a claim on commercial value when source code becomes part of a production system that makes money.

The threshold

The system should be free until there is a real business.

That is not just politics. It is market design.

If the threshold is too low, the license becomes compliance spam. It scares away developers, hobbyists, researchers, small businesses, and experimental users. It creates a thousand edge cases and turns public software into a paperwork trap.

If the threshold is too high, the software becomes free labor for companies large enough to monetize it but not large enough to trigger payment.

The line should be attached to relevant service revenue, not total company revenue in the abstract. A car dealership selling cars through a website should not pay because a package helps render its booking page. A SaaS company selling uptime, data processing, multiplayer game hosting, API access, managed workflows, financial infrastructure, or compute-enabled services should pay if the covered runtime is part of the sold service and the revenue is above threshold.

The hard rule is this: do not tax incidental use. Capture value only when public software is a direct input to a paid service.

The Deployment Box

The unit of measurement is the Deployment Box.

A Deployment Box is not necessarily a Docker container, though a Docker container can be one. It is a generic runtime unit that can describe a container, Kubernetes pod, VM image, serverless function, managed service runtime, appliance image, or future execution environment.

The Deployment Box contains a runtime graph.

That graph answers a simple question: what public software is actually running under the hood?

It is not enough to scrape a package-lock file and pay every package that appears. Build-time dependencies, test-only packages, unused modules, vendored code, and one-off imports should not automatically receive commercial payouts. The system needs runtime evidence: loaded libraries, executed modules, container images, kernel and user-space layers, language runtimes, security libraries, databases, orchestration components, and other dependencies that materially support the service.

Software bills of materials already point in this direction, but an SBOM alone is not enough. The OpenSSF and Linux Foundation's Census III study shows both the value and the difficulty of measuring open-source usage at scale. The report was derived from more than 12 million observations of FOSS libraries in production applications at more than 10,000 companies, and it highlights the continued need for standardized naming schemes for software components.⁶

The Deployment Box is the commercial version of that measurement problem.

It should not inspect customer data. It should not report secrets. It should not become surveillance infrastructure. It should report the public software graph, version identifiers, runtime presence, resource bands, and deployment class needed to allocate the value-capture pool.

The Open Compute Guild

The Open Compute Guild is the policy engine and accounting organization.

It is not the Linux Foundation with a new logo. It is closer to a clearinghouse, tax office, standards body, and statistical agency for public-goods software value flows.

Its job is not to decide which software is morally worthy. Its job is to decide which software is measurably present, commercially material, and eligible for payout under transparent rules.

The Guild would maintain:

• a project registry;
• maintainer and company payout identities;
• standardized package identifiers;
• Deployment Box reporting standards;
• fraud and gaming rules;
• threshold definitions;
• payout weights;
• audit procedures;
• appeals;
• public statistical reports;
• cloud-provider settlement rules.

This will be messy. That is why it needs an institution.

A Linux kernel running a Python program should not split the value pool 50/50 with the Python script. A cryptography library may be small in byte count and enormous in value. A framework may be visible while a lower-level library carries the security burden. A database may consume most of the resources. A package may be loaded but irrelevant. Another package may be rarely visible but operationally critical.

There is no silver bullet.

The Guild's job is to make the approximation good enough that money can move.

Over time, the Guild would publish BLS-style or IRS-style reports: which categories of public software are most used, which projects are systemically important, which packages are undermaintained relative to deployment share, which ecosystems are accumulating dependency risk, which maintainers receive payouts, and where the value flows are concentrated.

This is not just payment infrastructure. It is macroeconomic measurement for public software.

The incentive to reduce dependency hell

A good Open Compute License should not reward dependency bloat.

If every package creates a new fee, the ecosystem gets worse. Developers will add packages to extract rents. Companies will avoid public software to avoid compliance. Maintainers will split projects into artificial fragments. The license becomes a parasite.

So the customer bill should not rise just because the dependency graph gets longer.

The value-capture pool should be fixed by the commercial deployment, then allocated inside the pool. If a software company can do the same job with 10 meaningful dependencies instead of 200 incidental dependencies, the meaningful dependencies receive a larger share. If someone adds a trivial package to a major production environment, that package dilutes the pool unless the Guild determines that it is statistically significant and materially used.

This changes the incentive.

Today, dependency sprawl is cheap for the developer and expensive for the ecosystem. Under Open Compute Licensing, a tighter runtime graph can be more valuable. A small, precise package with few dependencies can capture more value than a bloated wrapper that imports half the registry.

That is the right direction.

Anti-gaming

The obvious attack is fake significance.

A developer installs npm check_time on a work environment that pays millions to AWS. His roommate maintains check_time. The package appears in a major runtime. The roommate claims a payout.

This should not work.

The Guild should pay only statistically significant runtime presence. One-off appearances should be ignored. Customer-specific anomalies should be discounted. Packages should be weighted by cross-customer ubiquity, runtime materiality, resource footprint, dependency centrality, maintenance burden, and critical-path function. A package that appears in one large customer should not be treated the same as a package that appears across thousands of independent deployments.

The empirical shape of open-source usage helps here. Open-source ecosystems are heavy-tailed. A small number of packages and projects account for a large share of real production usage, while the long tail is hobby work, local glue, experiments, wrappers, one-off scripts, and good-faith but non-systemic code. The long tail should remain free and public. The system should not become a payout casino.

The Guild's job is to pay the public software that has become infrastructure.

Why this is not just open-core

Open-core is the dominant working business model because it gives a company something to sell.

The public version creates adoption. The private version captures enterprise value. Hosting captures operational value. Brand and tacit expertise matter because the original authors often remain the best operators of the system even if competitors can legally run it.

That model works.

But it also changes what gets built.

Open-core rewards software that can be divided into free and paid features. Managed hosting rewards software that can become a cloud service. Consulting rewards software that creates support demand. Enterprise sales rewards software that can survive procurement.

Public goods do not always look like that.

A better compiler pass, a safer parser, a more reliable scheduler, a faster runtime library, a better security primitive, a lower-latency queue, a memory-safety migration tool, a less awful build system, or a dependency-reduction tool may be widely valuable without becoming a natural SaaS company.

Open Compute Licensing lets a small team write public software without having to deform it into an enterprise feature matrix.

The market pays when the software becomes part of commercial runtime.

Why hyperscalers are the first target

In principle, every commercial service operator above threshold should pay.

In practice, enforcement should begin where the runtime is concentrated and billing is already metered.

That means hyperscalers.

AWS, Microsoft Azure, Google Cloud, and the next tier of cloud providers already sell the compute. They already issue the bill. They already know enough about the deployment environment to support logging, security scanning, metering, autoscaling, cost allocation, and compliance products. They are few enough to negotiate with, regulate, audit, or certify.

This is not because hyperscalers are uniquely evil. It is because they are uniquely legible.

They also benefit heavily from public software. Cloud platforms package open-source components, operate managed versions of public projects, build internal infrastructure on public code, and sell compute to customers whose applications depend on public code. A small value-capture pool would recognize that public software is part of the production input stack, alongside hardware, power, networking, and labor.

For the cloud provider, the Guild can be a compliance layer and product feature.

For the customer, the charge can be part of the cloud bill.

For the developer, the payout can arrive without begging for donations.

Scope limits

This proposal does not cover all software.

It is mostly about server software, runtime infrastructure, application libraries, language ecosystems, and cloud-deployed services. It does not naturally cover desktop software, local tools, embedded firmware, offline applications, or every internal enterprise deployment. Those may need separate mechanisms later.

That limitation is a strength.

A new licensing economy should begin where measurement and value flows are clearest. Commercial cloud runtimes are the obvious starting point.

Do not begin with every laptop.

Begin with paid services running on metered infrastructure.

Failure modes

Open Compute Licensing can fail.

It can become compliance theater. It can be captured by hyperscalers. It can be captured by foundations. It can overpay visible frameworks and underpay boring substrate. It can create incentives to game dependency graphs. It can punish small companies if the threshold is wrong. It can create privacy risk if Deployment Box reporting is too invasive. It can become impossible to reconcile across forks, vendored code, patched versions, and transitive dependencies.

These are real problems.

They are also the problems that show why an accounting institution is necessary. A license alone is not enough. A package manager is not enough. A foundation grant is not enough. A GitHub Sponsors page is not enough.

The proposal needs a clearinghouse because public software has become economic infrastructure.

Economic infrastructure needs measurement.

The thesis

Open source solved access.

It did not solve value capture.

The old model says: make the code public, let everyone use it, and hope value returns through jobs, grants, donations, foundations, reputation, support contracts, open-core, or hosted services.

That model built the modern internet.

It is not enough for the next layer.

Public-goods software should remain public. Small users should not pay. Hobbyists should not pay. Researchers should not pay. A car salesman should not file a report because a JavaScript package helps his website run.

But when public software becomes an input to a paid cloud service, and that service crosses a meaningful threshold, some of the value should flow back to the people maintaining the public good.

The cloud bill is the collection surface.

The Deployment Box is the measurement unit.

The Open Compute Guild is the accounting institution.

The Open Compute License is the contract primitive.

A market economy for public-goods software does not mean enclosing the commons. It means letting the commons receive income when the market builds on top of it.

Sources