★ “Which Open Source Licence” Is The Wrong Question

Mesa Verde Cliff Palace DetailVarious commentators are beginning to pick at the threads of the rediscovered collaborative model for open source now that the “open source bubble” is being superseded. This is a return to what many of us regard as “real open source” (the co-development of software by a community of people who align a fragment of their self-interest in order to do so, using their software freedoms under an open source license and open governance).

Glyn Moody asks the question of which open source licence is best for the new wave and comes to the conclusion that the problem that’s faced open source projects in the “bubble” has been less licence choice and more the practice of corporate control via copyright aggregation. I have more to say on this subject in a forthcoming essay.

Glyn’s article has triggered a somewhat strident response from Matt Asay, who picks up a surprising message that I find hard to read in Glyn’s article. He asserts that Glyn (and I) are advocating that the businesses participating in the new collaborative wave should use proprietary software to earn their revenues. This assertion appears 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.

I believe the seed of this view is a riff on one of the oldest arguments in software. To comment on it, I first need to get philosophical for a moment.

Cause and Effect

There are two views of the place of “cause and effect” in the world. One believes in direct causality, the other 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 prove 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 computed 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 directly causal view, believing that the freedoms of software users are so important that there should be a direct compulsion on every user to share improvements they make to code. Glyn is clearly in the GNU-ish, directly-causal camp, concerned that people may not “give back”:

“This is the classic free-rider problem that the GNU GPL was designed in part to avoid. It means that contributors to Apache-licensed projects must be willing to accept that their work may well end up in closed-source products, maybe multiple times.”

The BSD-ish view is systemic, believing that any innovative user of the code will want to add their improvements to the commons so that the community around the commons will maintain them collectively, freeing the innovator to spend time elsewhere.

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 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…

Asay makes an unwarranted leap in his description of me in his article. I am a firm believer in the concept and philosophy of software freedom, but that doesn’t mean I believe the only way to achieve it is through directly-causal compulsion. Indeed, 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.

Contrary to Asay’s accusations, I’m not interested in the sort of “purity tests” into which FOSS fundamentalists spiral; I do, however, object to use of the term “open source” to describe a project where the participants are not all equal-by-rule. 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. I don’t believe creating artificial scarcity through proprietary code is a smart or scalably profitable action, so frankly Asay’s accusation I’m promoting proprietary development aren’t offensive; they are just irrelevant.

So Which Licence?

That’s where the argument of which license to pick needs to follow the sort of logic Carlo Daffera offers rather than the GNU-ish vs BSD-ish path. It’s hard to believe we are still having “which licence is best” arguments eleven 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 scarcity” argument.

The reason I believe “Open Core” approaches will become scarcer and scarcer is that the control-freak behaviours they necessitate (like demanding copyright ownership as a precondition of community participation) 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 thus the opportunity – for everyone.

[First published on ComputerWorldUK]

2 Responses

  1. Likewise, Matt seems to draw sustenance from Marten Mickos’ remark that the best way to support open source development is to make money from it, so you can hire more open-source developers. Marten’s been saying that for a long time. It used to be more convincing than the present state of MySQL forks and acquisitions allows.

    • I agree with Mårten’s statement to a large degree. Since open source projects are the synchronisation of the fragmentary interests of many parties each paying their own way, the more money each of them is making from the synchronisation of their interests, the more of it will happen. So the best way to support open source development is to make money from it.

      However, that does not mean anything that makes money for a company engaged with open source is good for open source. It’s not OK to cripple an open source community so that one member can make money from it. See http://blogs.computerworlduk.com/simon-says/2010/08/on-contributor-agreements/index.htm for example.

Comments are closed.

%d bloggers like this: