Sovereign Software Must Change
For years, the awareness of software sovereignty has grown bit by bit, showing up in various initiatives and conference talks (like the one that inspired my Sovereign Lumber post last year). But it’s only this week that major news outlets picked it up: NY Times, Associated Press.
What’s boggles the mind is that the model still doesn’t work. The problem isn’t solved. It’s merely identified.
Let me summarize what I laid out in the Sovereign Lumber post:
- Open source works for lumber (infrastructure, developer tools) but not for chairs (polished end-user software).
- End-user software’s value lies directly with its end-users.
- OSI-style open source licenses make monetizing the core product from users effectively impossible. Products in this space either go proprietary or stagnate.
- Successful commercial software gets revenue from end users, and reinvests it into continued maintenance and development, creating a feedback loop.
- A government interested in sovereignty cannot on its own replace revenue from end users. It’s neither scalable nor politically justifiable.
- Bottom line: the incentive problem is unsolved, and the model doesn’t work.
But what about this French Visio service, the alternative to Zoom and Microsoft Teams, which the French government developed and open-sourced?
It proves the need, but it doesn’t provide a solution. Funding for it comes from the government. In other words, from French taxpayers. Imagine this open-source product becomes good enough to be used by other governments and many large companies. Will France continue investing in it? Let’s imagine yes, they are generous. But can it possibly stay better funded than a product that’s paid for by many governments and large companies, rather than by just one?
In this model, a single user is paying for all development. This can’t scale. It can’t compete with commercial software. For end-user software, this has never worked well.
Independence
I really want to talk about solutions, but I need to explain another problem.
For software, being open source is not enough for trust or sovereignty. Should your Western country rely on open-source software funded purely by Russia, or China, or whatever other country you don’t trust today? If another country switches to the French-build Visio for important uses, would that be due to its open source nature, or due to trusting France?
A year ago, it seemed weird and wrong to worry about EU and US exploiting opportunities for an attack or compromise against each other. This year, it’s still weird, but it’s no longer wrong to worry. “Good fences make good neighbors” seems the prudent philosophy. The surge in sovereign software efforts shows that EU agrees.
If each country makes its own suite of productivity software, that’s a waste of resources, and almost certainly a disservice to end-users in terms of quality. That’s why open-source is all the rage.
So what would it take for a country to trust its open-source software?
"Trust, but verify"
Simple: they have to verify it. That’s a big value of the source’s openness. Open source makes it possible. Call it auditing. Or, if you are a developer, call it code reviews. Very thorough code reviews, particularly for security.
If you are a developer, you’ll know that code reviews are hard. You need real software engineers who understand the code. They’d have to be as good as core maintainers of the software. They’d spend a lot of time on reviewing the code. If you don’t do a thorough job, you’d better trust the maintainer to be neither a vector for a compromise, nor lax enough to let compromised contributions through. If you do it well, then it’s OK for the maintainer to be untrusted. Hard as it is to audit software, it’s easier than developing it.
Actually, the French understand this well. There are at least two products in their digital “La Suite” that are based on open-source software developed by non-French commercial companies, rather than in-house. One is Tchap that’s a fork of Element. The other is Grist (or which I am a cofounder).
In case of Element, the French wanted certain changes at one point, but didn’t agree on the price. “Good thing it’s open-source,” someone must have said. “We can fork it” — jargon for working on a copy — “and make our changes there”.
The problem with forking is that all further development on Element became harder and harder to incorporate into the forked coy. But when you fork, you want to incorporate changes, or your fork will stagnate. There are bug fixes, little features, big features, security vulnerabilities. Software needs maintenance. The French team made an effort for a while, spending more, I am sure, on the merging work than they would’ve paid Element for the feature in the first place. I think they no longer try. Now they are stuck with their own software, which no longer benefits from Element’s development. The French taxpayers are paying for it, as they are paying for Visio.
For future projects they swore off forks. When they decided to bring Grist into the suite, they knew what they wanted: their own serious developers who understand the code base and can contribute to it, and a well-functioning collaboration with the core team, which is an American commercial company, Grist Labs. The French team have the know-how to audit every change in Grist. They have engineers on staff who can fork if there is a conflict. But there are incentives on both sides to avoid a conflict: forking helps no one.
Sounds good? There is a major flaw here. What they are not doing is paying for the core development. Nor are they paying for licenses. In fact, the software is truly open source — licensed to be free as in “free speech” and also as in “free beer”. Actually, Grist has proprietary parts — it’s open-core because monetizing is effectively impossible otherwise — but the mandate of the French suite is independence. They aren’t using the proprietary parts. And they have the expertise to ensure that the freely-licensed open source core is good enough for them.
The effect is that the freely-licensed open-source core is very nearly good enough for anyone. So monetizing is very nearly impossible still. So where does the money come from for core development?
OK, we have the background in place. So what’s the solution?
Open source vs what matters
“Open source” has become a convenient label, but it can mean many things. To commercial companies, it may include restrictive source-available licenses such “Business Source License”, “Elastic License”, “Functional Source License”, and more. To most engineers, open-source means “OSI-compatible”. In particular, OSI-compatible licenses must allow free redistribution. These in effect preclude monetizing the right to use. To even more die-hards, “open source” isn’t good enough, but the goal is “libre software” enforced by “copyleft” licenses like GPL.
The sovereign software suites that are taking off now in Europe seem to have settled on “OSI-compatible”. Visio is under MIT license. Grist is under Apache license. Everything in the nascent Dutch suite is under an OSI-compatible license (see list here).
That is a mistake.
OSI-compatible licenses make for software whose development is fundamentally not monetizable. That’s the point of them. People want software to be free. Governments want software to be free. But who pays? For end-user software, if it’s free to use, then no one pays. No ad revenue. No subsidizing from the sale of hardware. It means the development relies on volunteer labor or on funding by taxpayers.
Governments ought to know — that’s not actually free. That’s much more expensive than software funded by satisfied customers.
I want to convince you, whom I’ll assume to be an open-source die-hard — perhaps in charge of some country’s digital sovereignty initiative — to embrace non-OSI-compatible software instead. Software that can charge money. And to do that, I want to highlight what actually matters, and make sure we keep that, and keep the funding by satisfied customers.
Auditability
The first thing that matters is auditability. That’s what “open source” literally means: you can see the source code of the program. You can read every line, and then you can build it from source, and get a functional product that will work in production.
If you are an individual, you don’t actually audit your open-source software. You can’t possibly have enough time. But if you are a government, you ought to. At the risk of a digression, I’ll even propose how. Get together a team of developers responsible for a particular piece of software. Make it international, collaborating with your allies. Get AI to help with reviews. This team will review every change, and tag it — for example, as “Reviewed by EU”. You’ll only ever build the versions that got that stamp. Anyone who trusts you will build from those versions. Others might build from versions that US tags, or another group of countries, or some commercial consortium. The point is: if you really care about security and sovereignty, you need sovereign expertise to audit the software. But you don’t need to develop it.
In technical circles, this property is called “source available”. That’s part of what OSI requires, and it’s also part of non-OSI “open-source-like” licenses such as BSL.
Self-hosting
The second thing you need, which might go without saying, is to be able to run the software on your own infrastructure. If you don’t, you don’t even know if the software comes from that source you audited. As importantly: all software works with data. If you want software sovereignty, you want data sovereignty even more. If the software only runs on a proprietary OS, you don’t have independence. If it only runs on proprietary hardware, you don’t have independence. You need to be able to run it on your own computer, or in your sovereign cloud. The jargon for this is “self-hosting”.
Libre-ish, not free
The third thing you need is the right to use the software independently of its license-holder’s wishes. That’s really the sticking point. If the software is to be funded by customers, you are such a customer. You should want to pay for it. No, really, it is cheaper for you if you are paying for it alongside other governments and a whole lot of companies than to develop it yourself. But once the creator has the pricing power, they got you good — the more dependent you are, the more they can raise prices. And they will. And sometimes they’ll stop all development and still raise prices. And if you have a political conflict, they won’t renew the license. (And if you are also not running on your own infrastructure, they may lock you out on the spot, as with Khan’s ICC email.)
What I propose is an incentive structure to give customers a way out of paying higher prices, but also a reason to stay. It’ll give the vendor a way to serve customers who demand independence, and a reason to keep them from leaving.
In case of emergency, break glass
The idea is to focus on what happens when things go wrong.
The vendor can jack up prices or refuse to renew your license. So let’s give customers a way out — a way to fork the project. It’s OK if it’s neither free nor painless. In fact, the point is to strike a balance where the optimal path for everyone is fair prices that get paid and that fund continued development without forking.
The way out requires two parts:
- Time-delayed conversion to an OSI-approved open source license. Let's say after 3 years.
- The right to pay a “severance” at renewal to stay on the current version until the time-delayed conversion.
Let’s say you are a big organization paying a large amount annually. When it’s time to renew, the vendor could say: your price will now be 10% higher. Or 50% higher. Or “we are no longer allowed to do business with you”. Let’s leave aside the strategy of violating the license. Availability of source makes it possible, but we'll assume the world order is not so hopeless.
What the license would allow you — completely legally — is to say that you are not happy with the conditions. Then you have the right to pay the current price for 3 more years, and keep using the version you are running at the moment. At the end of that, this version becomes OSI-compatible open source (due to the time-delayed conversion). So in effect, you get a perpetual right to use the current version.
Once you exit, you may use the software forever. You may modify it and maintain it yourself. You do not get updates. You may not redistribute it. You may not compete with the vendor. You are on your own.
This is not free software. It is not even generous. Maintaining software yourself is expensive, risky, and unpleasant. You lose updates, fixes, and new features. You lose the vendor’s expertise. You are frozen on a snapshot for 3 years.
But there is also the time-delayed conversion. That means that a version 3 years older is free and libre. The version you have today will be free and libre in 3 years. So you may join forces with other disappointed users to maintain it. You could even try to monetize it. You can redistribute it, and compete with the vendor. You are 3 years behind. But you are not hostage to the vendor.
Consequences
This single clause changes the power dynamics.
In normal commercial software, the vendor acquires asymmetric power once the software is deeply embedded. With this escape mechanism, extreme pricing becomes dangerous for the vendor. If prices spike, customers don’t need to scramble for an alternative on a deadline. They can exit calmly, pay the agreed severance, and keep running.
If the vendor raises prices moderately, customers will usually stay. Paying is cheaper than self-maintaining software forever. That’s exactly the balance we all want.
If the vendor gets greedy, enough customers will leave that the vendor may not survive. If the vendor stops maintaining the software, customers can band together and catch up the 3-year old libre version and maintain it themselves. That option is an important check on the vendor.
To the user, it’s not free as in free beer. But it’s much better than classic proprietary software. No major vendor today lets you buy a perpetual, source-available snapshot of their product. That option alone dramatically reduces dependency risk. The right to redistribute it freely after the delay, and to collaborate on it with others, reduces it further.
To the vendor, this would allow monetizing software from customers who require independence. By playing nice, no customer needs ever leave. The vendor that actively maintains the software is always 3 years ahead of anyone trying to take advantage of the time-delayed conversion. End-user software decays quickly. No serious customer should risk missing on the fixes or security updates. Even if they choose to exit, the vendor gets paid a substantial price.
Conclusion
I speak as a special vendor: Grist Labs has a uniquely positive and successful collaboration with La Suite. But not in terms of business. There is no money in it. Investors tell us to ignore European governments and focus on American businesses. To make important parts proprietary. For business success, they are right. But we made Grist open source for a reason: we are open source die-hards ourselves. Those values that matter to sovereign suites, they matter to us too.
So listen to me when I say this.
Sovereign software suites should move away from OSI-compatible licenses. They should embrace a license that requires a commercial paid agreement. In return, this license must give customers a way out: a time-delayed conversion to an OSI-approved license, and a “fire escape” to allow leaving calmly.
This proposal isn’t about being nice. Playing nice doesn't work. It’s about aligning incentives.
- Customers get software they can trust, and protection against predatory pricing.
- Vendors get paid by customers, not sovereignty initiatives driven by politics of the day.
The structure makes it possible for “open source” software to thrive by striking a good balance. It just needs to be embraced by the big users.