Need to send a file most people won’t need to edit? Send a file that’s both editable and final form at the same time, a kind of Schrödinger’s Document – a Hybrid PDF.
One of the scourges of e-mail is file attachments, and particularly those from people sending files made by their newly updated word-processor or presentation programme that half the people receiving it can’t open. While proprietary software vendors love this errant behaviour (it keeps up the pressure for people to re-purchase software they don’t really need so they can read other people’s work – AKA “upgrades” – or to subscribe to an online service that keeps them trapped), it’s really anti-social behaviour.
Interoperability is primarily a matter of the use case, not of the technology. Policymakers considering interoperability mandates need to be watchful for extremes of perfection or compromise, which both offer a game to be exploited by the unscrupulous.
Reviewers of a paper concerning interoperability complained that some sections seemed to imply only 100% functional equivalence would be acceptable, and told us “much smaller percentages are perfectly adequate.” So how much interoperability is enough interoperability? The answer, dear to the hearts of every politician, is “it depends”.
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.