Webmink In Draft

On the recent surge of single-vendor open source projects switching to non-compete licensing

Two concepts from my early career seem mostly disregarded today in the wake of the popularisation of free software by the open source movement. One is software reuse; the other is source-available proprietary software.

Software reuse was a major thrust at IBM when I joined in 1990. IBM wanted its developers to reuse the work of others, but few developers were interested in learning to use someone else's approach to solving part of their problem even assuming they could find and be allowed access to the code that did it. Even within a single company, reuse without community was unwelcome; it is all the more so in a context where you may also need to negotiate rights.

I remember source-available from visits to data centres working for Burroughs (now Unisys) in the late 80s. Big piles of tapes (and later CDs) stood in the corner of machine rooms, mostly unopened. Having the source code may help some users fix their own installations, but generally the point of a paid service contract is to have experts do that for you. It seems contradictory to try to charge the people who want source – it flies in the face of the time-weathered wisdom of Mårten Mickos:

To make money on open source, you give it for free to those with more time than money, and you charge a fee from those with more money than time.

Both reuse and source-available faded from focus once open source software became dominant in the early days of the millennium. The only people mentioning either were those trying to pretend they were offering open source when their licensing said otherwise.

Blowing In From The Past

So who is interested in them today? Not software developers, who now expect the flexibility that comes from being given all the rights necessary to use, improve, share and monetise a piece of software without seeking further permission or even clarification from the copyright holders. Not software users, who want those same freedoms so they are protected from vendor control and gouging.

No, they have been rediscovered as values by rights-ratcheters looking for a sheepskin for their late-stage wolf. As well as enabling innovation and liberating users from lock-in, open source does an excellent job of driving adoption of good software. Developers will reuse it as part of their solutions and go on to fix bugs and add new capabilities. Users will deploy it with confidence and are more likely than not to spend money with experts to configure, deploy and extend it.

But that strength is open to abuse. When the control of the copyright becomes concentrated (either because a simple non-reciprocal license like MIT or BSD is in use or a copyright assignment is used by a single vendor), when the core committers are employees of a single vendor and (most importantly) when the company involved is running using borrowed money, there is a great risk that the rights-ratchet model will come into play.

Pioneered about 15 years ago by a company called SugarCRM, the rights ratchet model sees software taken through a seven stage process from fully open to fully closed, with just a ratchet-click of reduced freedoms and withdrawn rights at each step. With a flurry of new companies using open source to drive adoption at the turn of the first decade, we might expect there to have been a number of companies reaching the late stages of this model about now. Indeed, that is what has happened, with companies of that era such as MongoDB, Elastic, HashiCorp and now Redis reaching stage 6 and switching licenses in a way not generally benefiting the community. It's less a trend than an expected evolution that will pass with the model.

It is a detectable marker of the presence of the rights-ratchet model that its exploiters are keen to wrap themselves in “open” credentials. So they raise ideas from the past and attempt to re-animate them. Some even try to argue they are somehow “redefining open source”. A favourite sheepskin is the argument that they are just making open source sustainable and forcing freeloaders to pay fair shares of the cost of development.

Fair Shares?

That last argument is seductive – we all think the worker should be paid for their work, and have our own job and household as a model. But it's a mistaken view in most of these cases, just as is the political trope of comparing the budgeting of a national economy to a household budget. The whole point of open source, from day one, is that users are free to do what they want with the code and everyone involved is solely responsible for the dynamic and economics of their own involvement.

A company using an adoption-led business model understands this viscerally, and will always have a plan to accommodate it. None of the examples cited above has shown any indication of lacking sufficient funds to maintain, improve or even create a cash surplus from the project in question. Rather, every one of them has reached a point of success where they want to move on towards the next stage for their investors. After all, investors don't invest in products, they invest in exits.

So do we need a new model for open source that accommodates non-compete restrictions, as the apologists for each of these rights-ratchet changes assert? No, of course not. What we need is a way to help people know the ratchet is closing in on them so they can fork earlier.

To discuss this post please reply from Mastodon etc. (search for the URL) & include @webmink@meshed.cloud as WriteFreely still doesn't display replies. More.