Free software never promised free labour

Asking people to pay for OSS is not some betrayal of the original free-software ideal.

“Free” was never supposed to mean “free as in beer”, as Richard Stallman has been saying for decades.

And yet, whenever an established OSS project introduces a commercial model, the discussion quickly seems to collapse into two extremes.

Maintainers should work for free forever.

Or:

It is my project, so I can change the deal however I want.

I don’t find either particularly convincing.

A license is a backward-looking promise

To me, the license attached to a release is a backward-looking promise.

If I publish some code under MIT today, I am giving people those rights to that code.

If I publish another version under MIT tomorrow, I make the same promise again.

What I am not promising is another release after that.

Or another bug fix.

Or another evening spent maintaining the project.

OSS consumers can sometimes be incredibly entitled towards maintainers. Using a library does not buy you the maintainer’s future time, particularly when you paid exactly zero for it.

If a maintainer decides to stop, archive the repository or hand the project to somebody else, that is entirely legitimate.

The license tells you what you can do with the software they already gave you. It doesn’t conscript them into maintaining it forever.

Changing the deal is different

At the same time, some changes in established .NET projects have never sat particularly well with me.

AutoMapper and MediatR are recent examples. Starting with AutoMapper 15 and MediatR 13, the projects moved to a dual commercial and RPL licensing model. Previous releases remain available under their original licenses.

The transition from IdentityServer4 to Duende IdentityServer was another, somewhat different, example years earlier.

My problem isn’t that their authors want to make money.

They should be allowed to.

My discomfort comes from how mature OSS projects accumulate value.

People contribute code. They report bugs. They improve documentation. They build integrations. They answer questions. They advocate for the project and help make it the default choice in an ecosystem.

They do all of this while participating in a project with a particular social and economic model.

If I contribute code to an MIT project, I am consciously gifting that code to that commons.

I might feel differently when future versions containing work built by that community become something I need a new commercial relationship to consume.

Nothing about that necessarily violates the previous license. AutoMapper and MediatR, for example, explicitly preserve the old releases under their original terms.

But legally permissible and socially comfortable aren’t necessarily the same thing.

Free maintenance clearly doesn’t work either

The opposite answer, that everything should simply remain free forever, is not convincing either.

Heartbleed demonstrated this spectacularly in 2014.

OpenSSL was foundational infrastructure used across enormous parts of the Internet, while the project had very limited resources. The aftermath of Heartbleed was significant enough that the Linux Foundation created the Core Infrastructure Initiative specifically to identify and fund critical open-source projects that were under-resourced. OpenSSL was among the first projects to receive funding, including support for full-time core developers and a security audit.

The absurdity is hard to miss.

We had collectively decided that a piece of software was critical infrastructure while largely leaving its maintenance to somebody else’s available time.

Open source had been extremely successful at distributing the software.

That didn’t mean it had been equally successful at funding its maintenance.

Elastic and Redis found another failure mode

Elasticsearch and Redis exposed a different version of the same problem.

Their licenses gave commercial actors substantial freedom to use the software.

Cloud providers used those freedoms to offer commercial managed services.

Elastic eventually decided that the economics of AWS offering Elasticsearch as a service did not work for them and changed the licensing of future versions. The old Apache 2.0 releases could not be pulled back, and the response eventually included OpenSearch.

Redis followed a similar path in 2024 when it moved future releases away from BSD. The community response produced Valkey, based on the last BSD release and backed by several companies that wanted an openly licensed continuation.

In both cases, the old license did exactly what it was supposed to do.

The companies couldn’t revoke the freedoms they had already granted.

The community could fork the last release carrying those freedoms and continue from there.

In a way, that’s OSS working perfectly.

But restrictive relicensing, fractured communities and duplicated maintenance don’t strike me as a particularly efficient mechanism for making OSS sustainable.

Which brings us to OSMF

This is why I find the recent discussion around the Open Source Maintenance Fee interesting.

Jeremy D. Miller recently wrote about the open-core model he is using to fund Marten and Wolverine, while several .NET projects have started looking at OSMF for their published artifacts.

The fundamental idea appeals to me.

Keep the source open and preserve the freedoms attached to it, while recognizing that producing and maintaining the published artifacts commercial software relies upon has economic value.

The normal fee proposed by OSMF is deliberately small, typically $10 per month per project for organizations above the relevant revenue threshold.

More importantly, the fee isn’t meant to buy the source-code rights that an OSS license already grants.

It pays for continued use of the project’s maintained binary releases in revenue-generating activities. If you don’t want to pay, the source remains available under its open-source license and you can build it yourself.

That feels like a much more interesting boundary.

You’re not retrospectively selling the source code people helped build.

You’re attaching economic value to the ongoing work required to maintain, build and publish what comes next.

The dependency graph complicates things

There are still difficult questions.

Ian Cooper raised several good ones around the recent .NET discussion, and the Polly discussion about adopting OSMF is a useful place to see some of those edge cases play out.

Polly is an especially interesting example because its value doesn’t stop with applications that reference it directly.

Microsoft’s Microsoft.Extensions.Resilience and Microsoft.Extensions.Http.Resilience packages are built on top of Polly, and Aspire client integrations are designed around resilience patterns such as retries, timeouts and circuit breakers.

That means an Aspire application can benefit from Polly without ever choosing Polly directly.

Under the current OSMF rules, that distinction matters. A commercial consumer pays fees only for projects it directly depends on, not every transitive dependency underneath them.

That seems right to me. If Microsoft chooses Polly as part of its resilience stack, an Aspire user should not suddenly acquire a commercial relationship with Polly simply because that implementation choice exists somewhere underneath a Microsoft package.

But it also exposes the harder question.

Microsoft gets substantial ecosystem value from having a mature resilience library it can build on instead of maintaining the whole stack itself. That value is real even when the Microsoft package above Polly is itself free OSS.

So who, exactly, is capturing the commercial value?

Is it the application developer?

Microsoft?

The company shipping the final product?

All three, in different ways?

The same ambiguity appears elsewhere too. What happens when software vendors build on other software vendors? Who is the ultimate consumer in a SaaS model? And what happens when a $10 monthly fee requires a company to establish a vendor relationship, involve procurement, review a EULA and track another recurring license?

The monetary cost can be almost irrelevant compared with the administrative cost.

OSMF already has a partial answer to the dependency problem. An OSMF project that itself generates enough revenue becomes responsible for the fees of its own direct OSMF dependencies.

So responsibility can already move through the dependency graph.

The Polly and Microsoft example makes me wonder if that idea can be pushed further.

Maybe it should work a bit like VAT

Not literally VAT.

Nobody needs NuGet to become a tax authority.

I’m thinking about the way the economic burden moves through a supply chain until it ultimately reaches the party consuming the finished product.

If Microsoft’s resilience packages depend on Polly, Microsoft is the actor that made that dependency choice. If my application then depends on Microsoft’s package, I shouldn’t need my legal department to understand the complete tree underneath it.

Likewise, if my OSS library depends on another OSMF-funded library, I shouldn’t necessarily become the economic endpoint just because I happen to maintain the package immediately above it in the graph.

Perhaps the obligation can flow through the software supply chain instead.

The party ultimately turning that stack into commercial value bears the real economic cost, while intermediate projects account for the dependencies they deliberately introduce.

Tooling knows the dependency graph already.

It could calculate attribution, collapse duplicate paths and eventually help distribute the appropriate amount upstream.

That would make OSS maintenance fees less like thousands of tiny vendor relationships and more like an accounting mechanism attached to the software supply chain.

There are plenty of corner cases to solve.

Internal enterprise software isn’t quite the same thing as a product being sold.

SaaS makes the idea of an ultimate consumer fuzzy.

A commercial library vendor sits somewhere in the middle of the chain while also deriving value directly.

And Microsoft’s use of Polly illustrates another problem: strategic value doesn’t always show up as direct revenue from the package that depends on the OSS project.

Revenue thresholds and redistribution therefore need clear rules.

But these look like problems with the accounting model, not evidence that maintainers should continue working for free.

Who captures the value?

Maybe the problem was never that Amazon can make money from Elasticsearch.

Or that Microsoft can build a resilience stack on top of Polly.

Or that my employer can use NuGet packages to build commercial software.

Or that my own company could do exactly the same.

The freedoms that make those things possible are part of what made OSS successful in the first place.

Maybe the problem is simply that we still don’t have a particularly good mechanism for a tiny fraction of the value created at the end of that chain to flow back towards the people maintaining the infrastructure underneath it.

I don’t know whether OSMF, in its current form or an evolved one, is the answer.

But I like that it is trying to solve the problem without pretending that OSS was somehow a historical mistake.

Free software never promised free labour.

The challenge is finding a way to pay for what comes next without rewriting the promise attached to what was already given away.

Support this blog

If you liked this article, consider supporting this blog by buying me a pizza!