How similar are open source development and standards development? Not at all, and even the words they have in common mean different things in each.
It is often asserted that open source and open standards are in some way similar. For example, in the accompanying letter to a recent submission to the European Commission, a major European-based technology company that is very active is standardisation said:
In a (large) video meeting at virtual FOSDEM, someone joked that maybe this will finally be the “year of the Linux desktop”. One of the oldest jokes in the community. Everyone sniggered. But the joke’s on them: it already happened, like a thief in the night.
While we were all waiting for the open source community to topple Microsoft’s desktop monopoly by replacing the locally-installed operating system, we missed the real revolution. Sure, there’s still plenty of money in both operating systems and in desktop apps. Microsoft (and indeed Apple) will be milking that legacy monopoly for a good while even if they have started hollowing out themselves — on Linux. It’s certainly been the target of competitive attention from open source software from the beginning; indeed, the open source productivity suite family now epitomised by LibreOffice has over its long history done an effective job in opening up that part of Microsoft’s monopoly (even if mostly by triggering the creation of ODF).
The coming wave of digital regulation may claim to target “Big Tech” but will inevitably end up harming citizen-innovators most because regulators have forgotten to include them in their process.
Here come the regulators. “Big Tech” companies like Facebook and Google definitely deserve some guide-rails, as well as some consequences for the unwanted impacts they have foisted on society along with the desirable ones. Facebook in particular has some deep, serious consequences of its amorality due soon. But so far, pretty much every regulation relating to the digital realm is defective.
It’s not new, even if each time it comes up people think it’s a new outrage.
One of the durable long-term strategies for software businesses in the era of open source was perfected by SugarCRM about a decade ago. I’ve described it as the rights ratchet model. The “ratchet clicks” (not necessarily in exactly this sequence) are:
The open source network effect depends on unrestricted software freedoms. Licensing & business models that restrict those freedoms aren’t seeking the open source effect – or if they are they will fail – so calling a policy, product or company that does so “open source” is false advertising.
A focus solely on open source legal and licensing matters as they affect companies creates bad outcomes — for leaders and their advisers who are surprised by community and market reactions, and for developers who feel abused and betrayed by “open source companies” and “government initiatives” that actually put obstacles in their path rather than remove them. While the minutiae of open source licensing and governance need to be understood and accommodated, it’s vital to never lose sight of the open source effect itself.
All open source licenses are permissive. They give you permission in advance to use the software for any purpose, to improve the software any way you wish and to share the software with whoever you want. They are the opposite of proprietary licenses, which place restrictions on each of these freedoms. Any license with restrictions would not be considered OSD compliant.
All open source licenses include conditions. Some relate to attribution. Some relate to reciprocal licensing. None of them restrict how you can use, improve and share the software, although you must comply with the conditions in order to do so. Some people consider some conditions so onerous they rise to the level of restrictions, but the consensus of the community has been they are wrong.
Today’s licensing games are thus mainly about testing where the accumulated burden of conditions is effectively a restriction – “constructive restriction”. There’s certainly a line where that would become true – for example, where the conditions associated with deploying the software as a cloud service are so hard to comply with that the software is effectively unusable in that field of use.
The OSD doesn’t include much to help with this so it’s contentious every time and sometimes leads to sophistry. This is probably the area where the Open Source Initiative needs to do the most work to modernise the license approval process.
The lesson Elastic’s restrictive relicensing teaches is that those using open source to ratchet a software startup will forsake software freedom eventually if they’re aggregating rights. That’s no reason to believe open source needs updating.
Many of the responses to the decision of Elastic to drop open source licensing for their products and instead use restrictive commercial licensing have involved asking whether they were justified to do so based on market conditions (especially the provision of a service by Amazon Web Services) or diving into the minutiae of what they actually did. Some see it as support for the hypothesis that the very definition of “open source” is out of date. But to do so is to swallow the bait of distracting explanation and overlook the actual value of open source and why Elastic — and the cloud databases before them — no longer care about it.
We supported the Internet Society this year in preparing a white paper describing “Considerations for Mandating Open Interfaces”. Both European and US legislators are concerned by the market and political impact of large technology companies like Facebook, Apple, Twitter and Google, and a popular line of advocacy seeks legislation to regulate them through enforced interoperability.
At first sight, this seems highly desirable. Why should services like WhatsApp and Google Chat not be forced to interoperate so that users of one can chat with users of the other freely? Why should users of Twitter, Parler and Mastodon not be able to subscribe to each other’s posts and participate equally in their follower networks? But the devil as always is in the details. Means of achieving these things can easily turn out to be problematic, either for technical reasons like architectural incompatibilities or for more subtle competitive reasons. Indeed, it’s notable that the biggest critics of Google and Facebook are the almost-cartels of mobile telephony companies who see in these mandates a way to hobble their most dangerous challengers.
The resulting white paper raises as many of the issues as possible in its slim 32 pages, while also attempting to point at solutions for some of them. You can read the Executive Summary and download the full paper at the Internet Society’s resource page.