Software Freedom For Business Value

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.

All the values that make businesses pick open source software — both as alternatives to off-the-shelf software and now as elements of a platform strategy — are derived from software freedom. You can use the presence of software freedom as the ‘genetic marker’ for value to your business. Ensuring software freedom is delivered to the enterprise is a primary role of open source program offices (OSPOs).

The free software definition does indeed read like a revolutionary manifesto, partly because it is. The people behind it often eschew the pragmatism of the term ‘open source’ for historical reasons. But it’s worth looking behind their philosophy as it remains the heart of open source. I paraphrase the free software definition as guaranteeing the liberty to use, study, improve and share software for any purpose without further negotiation. Those four liberties are not important to you (only) as an ideology — they also create all the value of open source for business:

  • Being able to use the software for any purpose, without first having to seek special permission (for example by paying licensing fees or negotiating royalties). This allows developers to try everything and use what works. It also means suppliers need to demonstrate value beyond just access to the software.
  • The availability of skills and suppliers because they have had no barriers to studying the source code while also experimenting with it. The market in experienced staff, open source tools together with expert consultants is getting richer, and more vibrant by the day because of this freedom.
  • The assurance that vendors can’t withhold the software from you because anyone has the freedom to improve and re-use the source code. If a vendor decides to end support for open source software, another company can step in and carry on where they left off. If the capability you need isn’t there, you can get it elsewhere, have it written or write it yourself.
  • The freedom to pass the software on to anyone that needs it, even including your own enhancements – including your staff, suppliers, customers and (in the case of governments) citizens.

These freedoms also combine to deliver benefits associated with open source: the right to fork arises from all of them together; the ability to form a collaborative community arises from them; the ability to subset and super-set code as well as repurpose it in unrelated works arises from them; the ability to embed software in devices or scalably deploy in the cloud arises from them. All are easiest to appropriate when using software licensed under a community-reviewed, OSI-approved license.

When software users are deciding which suppliers to deal with, they need to know whether their software freedoms are being respected and cultivated, not out of a sense of philosophical purity but because their budgets as well as success depend on it. All the values that differentiate open source for the business user are the first derivative of software freedom. A primary role for an OSPO is thus to ensure that this value accrues to the company they serve and not (just) to a supplier.

Having meaningful markers governments and larger businesses can use in their procurement to favour open source – the software that lowers costs, avoids lock-in while also enabling unexpected future uses of data and software – is not an abstract matter of angels on pinheads or out-of-touch insiderism. It’s exactly the catalyst for innovation and value that the enterprises I’ve been visiting are asking for. Look for the genetic marker of business value –- open source that delivers software freedom to you and doesn’t have it exhausted elsewhere.

Permission Beyond Licensing

Is that single-company-controlled project actually open source in the sense of delivering software freedoms to you or just about delivering prospective customers to its host company? Here are 7 tests.

I frequently sum up the nature of open source licensing as granting permission in advance to developers or users to use, improve and share the software for any purpose. But the “Permission In Advance” lens has uses beyond just the rights to copyrights and patents granted in an OSI-approved license. 

In my consulting engagements, I use a “thinking tool” to help clients work through their proposals for new open source community activities. Evaluating a project’s licensing, patent, and community management strategy — both to join it and to host it — should begin with the question: “How confident are community members that they have permission in advance to do whatever they need to succeed?” The more reasons for confidence, the larger the community.

Here are some of the questions community members will be asking, perhaps silently, about single-company open source projects and their own agency as a member of the community:

1. Am I granted rights permissions? An OSI-approved license guarantees this; does it apply to all the code? If there are portions of the code that remain proprietary or wrapped in additional terms that amount to a “constructive restriction“, a community is not truly free to form around the code. Developers wanting to enhance or even deploy that portion of the code do not have permission in advance, so probably won’t want to join even for the portions where they do.

2. Am I free to use my chosen business model? Copyleft licenses may limit certain business models, but issues arising from them aren’t usually directly to do with their copyleft terms. Communities use the GPL very effectively where the playing field is level — the Linux kernel and the GNOME community both come to mind. More problematic is the use of strong copyleft license like the AGPL in combination with a contributor agreement that means the “project owner” is not subject to the terms of the license for their own trading. In these circumstances, one community member is free to engage in proprietary strategies while everyone else can only offer support or add-on businesses because any platform value-add would have to be donated to the business of that one community member.

3. Am I unlikely to suffer patent demands? It can never be prevented, but patent grants like the ones in modern open source licenses — plus corporate pledges and nonaggression alliances like OIN or LOTN — can all help. Communities with no patent grants to protect people can feel like the Wild West, with the concern anyone could show up with weapons any time you’re successful. While patent demands can always come from afar, most patents related to a given codebase actually arise close to where it was written. Projects built around de jure standards that permit “FRAND” patent royalty demands are also likely to find this will happen.

4. Am I free to compete with other community members? Community rules that prohibit — explicitly or tacitly — competition with the sponsor reduce freedom. That includes any attempt at field-of-use restrictions — which are banned in OSI-approved licenses but still show up in governance rules — such as “not for mobile use” or “not for cloud deployment” or “can’t be used for military purposes.” Watch especially for contractual controls outside the scope of the actual code, such as to participate in an app store or to use components or apps that are essential for participation in the platform ecosystem.

5. Am I free to contribute my improvements?  That’s a matter of the rate of acceptance of pull requests, of course. But it also applies when contributor assignments are a precondition to contribution. As well as creating inequality, they get in the way of participation, as does any mandatory agreement that will require legal review. I contribute back to reduce my maintenance and refactoring burden — it’s not (only) philanthropy. It’s reasonable for a community to expect me to demonstrate competence and ownership before giving me commit rights. It’s much less reasonable to insist I have to assign ownership of my work to a “project owner.” That chills participation, by forcing me to effectively pay to participate, both for legal advice and with code.

6. Am I treated as a development peer?  When a company’s employees have privileged access to the code (or unearned commit rights) they rob potential collaborators of the confidence they have space to innovate. A sure sign is changes that are conducted in private, then “thrown over the wall” to the community. Why would you invest in significant new work, only to find the “project owner” rendering all your work moot with a bolt-from-the-blue code update, license change or business move that turns the rights ratchet? All these moves are scornful of contributor equality. When the only way to be sure you’ve permission to innovate is to enter into a bilateral agreement with one company, you’re being treated as a client or partner and not as a community peer.

7. Is the project inclusive of all people and skills? How do you license your documentation? Can I contribute to it? What about your user support community? Can I join in both to get and to give help? Do you have policies to discourage harassment of people who don’t seem to fit into your community norms? If people need to ask for any of those, that’s a lack of permission in advance as well.

Using the lens of “permission in advance” turns out to be an easy and useful tool for diagnosing your community governance, and for an OSPO to understand concerns with projects their developers would like to adopt beyond mere licensing issues. The seven points here aren’t the only concerns; which do you use for your own purposes? I would be interested to hear what tests others apply to community and project governance to determine whether there is truly freedom to collaborate.

OSPOs As Community Advocates

Is your Open Source Program Office just part of your corporate defences, or is it the community’s advocate inside your company as well?

Supplies?

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.

Continue reading

Corporate Maturity As Stochastic Outcome

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.

Collective Behaviour

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.

Continue reading

How Much Interoperability Is Enough?

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.

How I Learned To Type

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”. 

Continue reading

The Missing Stakeholders

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.

Tracks in the snow suggest a bird being captured by a cat.
Stakeholder-Citizen Interaction

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.

Continue reading

The Rights-Ratchet Model

It’s not new, even if each time it comes up people think it’s a new outrage.

Caged Bird of Paradise

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:

Continue reading

Policy Distractions

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.

Woods Beautifully and Validly Concealed By Sunlit Trees

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.

Continue reading

A Bit Of A Stretch

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.

Camille Claudel's sculpture "The Mature Age" illustrates the abandonment of principle as the subject matures.
“The Mature Age” — Camille Claudel

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.

Continue reading

On Microsoft’s Journey

Nearly a decade on from my original journey model, how far has Microsoft really come? Are they now aligned with their peers?

A decade ago, I wrote about the journey corporations take as they move from treating open source as a threat to embracing software freedom as a corporate philosophy within their business strategy. It wasn’t a perfect model, but it had plenty of resonance for me and many others at the time. The steps were:

Continue reading