Is Open Yet Closed Still OK?

In these days of code that no single mind can grasp, it’s hard to see how software freedom is present when there’s no realistic community access to source code.

Copycat Tree

In the early days of Free Software, it was a safe assumption that anyone using a computer had coding skills of some sort — even if only for shell scripts. As a consequence, many advocates of Free Software, despite a strong focus on user freedoms, had a high tolerance for software that made source available under free terms without providing other access to the project, especially in the days when that meant tapes by mail.

Limited access was considered undesirable, but as long as the source code could be used it was not disqualifying. From this starting point, cumming entrepreneurial minds found many other ways to ensure that the software was somehow impractical to deploy without a commercial relationship with a particular vendor, even if the letter of the rules around Free Software was met.

This tolerance for “open but closed” models continued into the new Open Source movement. As long as code was being liberated under open source licenses, many felt the greater good was being served despite obstacles erected in service of business models.

But times have changed. Random code liberation is still desirable, but the source of the greatest value to the greatest number is the collaboration and collective innovation open source unlocks. While abstract “open” was tolerated in the 20th century, only “open for collaboration” satisfies the open source communities of the 21st century. Be it “open core”, “scareware”, “delayed open”, “source only for clients”, “patent royalties required” or one of the many other games entrepreneurs play, meeting the letter of the OSD or FSD without actually allowing collaboration is now deprecated.

As a consequence, OSI receives more complaints from community members about “open yet closed” than any other topic. Companies of all sizes who loudly tout their love for open source yet withhold source code from non-customers generate the most enquiries of this type. When approached, OSI contacts these companies on behalf of the community but the response is always that they are “within their rights” under the relevant open source licenses and can do what they please.

One claim that deserves to be soundly debunked is that it’s OK to withhold open source code from non-customers. All open source licenses should be interpreted as requiring source to be made available to the public. OSD 2 is very clear:

2. The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost, preferably downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.

Interestingly it’s common that the companies involved obtained the source code they are monetising under an open source license, while they themselves own the copyrights to a tiny percentage of the code. They can be considered to have enclosed the commons, enjoying the full benefits of open source themselves — and celebrating it — but excluding others from collaboration on the same terms.

Many community members would tolerate this were it not for the company claims to be strong supporters of open source. Even this behaviour might be mitigated for some with upstream code contributions. But in the absence of public code, most community members dispute something is open source, regardless of the license used. “Open yet closed” may have been tolerated twenty years ago, but today the rule is open up or shut up.

 

(First published by the Open Source Initiative, November 14, 2017, with the support of Patreon patrons).

Cause, Effect and License Choice

Choosing between licenses – even copyleft vs non-reciprocal – is less important than ensuring everyone has equal rights & responsibilities.

28527163435_4b7b9aae85_o

I’m often asked which open source licence is best for businesses who want to release a project as open source. Usually behind the question the issue is a desire for corporate control somewhere in the organisation. This tends to flow from a conviction the only way a business can succeed is by keeping some sort of copyright (or patent) control that creates an artificial scarcity.

Cause and Effect

I believe the seed of this view is a riff on an old, old argument none of us is likely to solve concerning the place of “cause and effect” in the world. One view believes in direct causality, another in systemic causality. Both are correct much of the time, so the difference between them rests beneath the surface of most realities. Both are tools in guiding behaviour and predicting consequences.

In most circumstances, direct causality seems the obvious interpretative lens for the past and predictive lens for the future. We are most comfortable when we can draw clear circles around causes and thick lines between them and their consequences. We admire the “chess players” of society who can draw long chains of clear circles and thick lines, and for most of us the ability to mentally calculate chains of cause and effect is limited to only a few steps.

But certain systems involve a longer chain of lesser causes and effects that makes a focus on the individual steps unhelpful. Things like evolution, national economics, global warming and terrorist networks all need a systemic view if they are to be properly understood, and a focus on what the individual can directly control leads to bad choices. These systems are especially difficult for people with “just do it” attitudes, who find it hard to take “on faith” that they should act in a contrarian way because of a larger system which can’t be seen and forecast in its entirety.

When our outlook is dominated by direct causality, we seek control over causes. When our outlook is dominated by systemic causality, we seek influence over the network of causes and effects. In many cases, both outlooks lead to the same decision, but as we have moved to a meshed society, the importance of systemic causality has risen. Every cause has an immediate effect, but to believe that effect is the only consequence is increasingly a risk.

If the distance to the effect we seek is short, and that effect is the only outcome that matters, control is obviously desirable. But if the distance to the desired effect is large and filled with many connections, it’s better to collaborate and co-operate with other participants and prioritise influence over control.

Two Views of Freedom

The tension between direct and systemic causality lies at the heart of the endless debate between whether BSD-ish (permissive) approaches to software licensing are better or worse than GNU-ish (copyleft-based) ones. The GNU-ish view takes a systemic view, believing that the mesh of outcomes depends on the freedoms of every software user and intervening to ensure those freedoms are passed on along the chain. This is the approach preferred by the Linux kernel, where every participant has a copyleft responsibility that they propogate along their supply chain. It’s created one of the most effective collaborative ecosystems ever.

The BSD-ish view is causal, believing that each developer should have the full gamut of rights and that their choices are paramount. Network effects are assumed to be emergent from the choices of individuals and not coercible. This is the view the Apache Software Foundation best expresses, and it clearly works well for them. They have large numbers of participants in a large number of successful projects, and in most of them there is no “tragedy of the commons” at work – self-interest does not require selfishness. It is in the interests of every participant to contribute their work to the commons upon which the fragment of their interests relates. Doing so reduces their own costs, increases the surface upon which the community innovates and gives the maximum return. People who don’t add their work to the commons are condemned to maintain their own work, alone, for ever…

So Which Licence?

Which is right? Clearly they both can be, given the correct conditions. I tend to believe that the key to a successful open source project and community is to studiously maintain equality among all the participants so that no one participant can become “more equal” than the others, giving systemic effects free rein. I’m not interested in arguing the causal vs systemic debate anew; I do, however, object to use of the term “open source” to describe a project where the participants are not all equal-by-rule. Software freedom is paramount; as Bruce Perens has confirmed,

“Open Source” is the proper name of a campaign to promote the pre-existing concept of Free Software to business

The most important factor is not whether it’s OK for community members to create proprietary code from a project; it’s whether everyone has equal rights/duties to either make proprietary versions or to comply with copyleft terms.  It’s hard to believe we are still having “which licence is best” arguments twenty years after the founding of OSI, but we are. Arguments over licenses rarely matter these days; all open source licenses are fully gamed. The reason collaborative projects are resurgent is not a “which licence is best” argument at all; it’s a “level playing field vs artificial privilege” argument.

I believe “open yet closed” approaches will become scarcer and scarcer because the control-freak behaviours they necessitate (like demanding copyright ownership as a precondition of community participation, or giving a vendor special trademark rights) just don’t lead to the greatest growth. I’m not sure I care much which licence you use, as long as everyone in your community has the same rights so that the most people possible can participate. That’s what will grow the community and the innovation – and thus the opportunity – for everyone. Doing so is not “giving away your IP”; it’s using it to buy the best innovation, collaboration and market growth that’s achievable in software.

(Made possible by the support of Patreon patrons. Please join them!)