A draft scorecard for determining if a software project is open as bait for a business pivot or genuinely keeping your freedoms protected.
The seven signs a project is following the rights-ratchet route to riches and the framework for going beyond licensing can be augmented by some straightforward indicators of an issue. None of these alone is necessarily a cause for concern, but the more clicks, the more risks. Here’s a rough-and-ready first draft of a scorecard to check whether your software supplier considers you a community peer and will respect and protect your essential freedoms, or visualises you more like one of those pods in The Matrix. Just count the clicks; the more clicks, the higher the risk this is a rights-ratchet that will end up closed.
Software freedom is important to as an idea, but it also creates all the value of open source for business and should be jealously guarded by OSPOs.
In talking about open source, I and others routinely use the expression “software freedom” to refer to the set of rights upon which the open source phenomenon is based. It arises as a synonym for “free software”, an unfortunately ambiguous term that leads people hearing it for the first time to conclude all the primary attributes of open source software relate to money — price, cost-of-ownership, license fee and so on.
“Software freedom” puts the focus in the right place — on the essential liberties required to benefit from the software. One problem with this alternative term is we are becoming accustomed to hearing discussions of “freedom” be limited to activist or political contexts, and consequently regard the term “software freedom” with caution. But a focus on software freedom isn’t just for the revolutionaries.
Is your Open Source Program Office just part of your corporate defences, or is it the community’s advocate inside your company as well?
As we considered before, corporations are not a person, but are rather a vehicle for the collective expression of the vision of many individuals, showing the outworking of the processes and systems they devise to embody their vision. So the work of an Open Source Program Office (OSPO) needs to address social change within the company and address community needs outside as well as compliance or other corporate self-protection.
Corporate open source maturity may be better evaluated by considering the actions of individuals and small groups statistically rather than evaluating the stated corporate strategy
It’s easy to forget that corporations (and indeed large non-profits) are not a person, but are rather a vehicle for the collective expression of the vision of many individuals, as well as the outworking of the processes and systems they devise to embody their vision. Things happen not because a faceless corporation somehow chooses to act in a certain way from a point in time, but because of the persuasive decisions of actual people, acting within their belief systems and directing the work of others.
Every good – and bad – decision ultimately goes back to an individual somewhere, and corporate effects are in many ways emergent. So fitting a maturity model to a corporation may not be the best way to predict its future outcomes. That is a trailing indicator driven by the behaviours of the individuals within the company.
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 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.
Open source software should not force acceptance of an End User License Agreement (EULA). In every context where an “EULA” is appropriately used, it’s describing the rights that an end-user and not a distributor is surrendering in return for the freedom to perform an act that would otherwise breach the copyright. The freedoms you need to use the software under open source licenses are granted unconditionally, and the freedoms you need to distribute and modify the software are conditioned on acts other than signalling acceptance of the license with a signature or a click-through.
I thus continue to assert that it is always unnecessary for open source software to present users with the license and demand an act of submission before proceeding. Demanding such an act is to be discouraged; it conditions users to believe that use of the software is subject to compliance actions.
There’s never a need for compliance or enforcement action on mere use (as opposed to distribution or modification). As has been written elsewhere, the freedom to use without seeking permission or proof of compliance is actually the key benefit of open source software and slavish recital of redundant EULA behaviour distracts users from this truth.
Do open source mandates work? Plenty of entities have tried to apply an open source mandate, requiring use particularly of open source office suites like LibreOffice. But it takes more than just a decision or a mandate; to successfully gain the benefits of open source in the enterprise, you also need a thoughtful migration plan. Read about this in our article today at Linux Advocates.