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!)

Permission In Advance

Open source ensures developers already have permission to innovate and don’t need to ask first.

28253135574_6d99710f6b_k

If you want your code to be open source, it needs an OSI-approved copyright license. Code with no license to the copyright isn’t open source. But project success needs more than just an OSI-approved license — it needs “permission in advance” for every developer and deployer. Continue reading

5 Reasons Facebook’s React License Was A Mistake

Facebook’s BSD+Patent license combo fails not because of the license itself but because it ignores the deeper nature of open source.

Beware Falling Rocks

In July 2017, the Apache Software Foundation effectively banned the license combination Facebook has been applying to all the projects it has been releasing as open source. They are using the 3-clause BSD license (BSD-3), a widely-used OSI-approved non-reciprocal license, combined with a broad, non-reciprocal patent grant but with equally broad termination rules to frustrate aggressors.
Continue reading

Apache Bans Facebook’s License Combo

The Apache Software Foundation has moved the “Facebook BSD+Patent grant” license combination (FB+PL) to its “Category X” licensing list, effectively banning inclusion of any software under FB+PL from Apache projects. That included RocksDB, which has consequently just dropped FB+PL and added the Apache License v2 on Github, and React.JS which does not look like it will resolve the issue so fast.

Update, 22 September: Facebook has announced it will switch React to the MIT license.
asf_logo

Here’s what we know so far (subject to updates, last day’s in green, latest marked 🆕): Continue reading

Why OSI License Approval Matters

Individual judgement about the presence of software freedom in a license is not the same as community consensus expressed through OSI approval.

Three Legged Buddah

Does it really matter if a copyright license is OSI Approved or not? Surely if it looks like it meets the benchmark that’s all that matters? I think that’s the wrong answer, and that OSI license approval is the crucial innovation that’s driven the open source revolution. Continue reading

Is The GPL Really Declining?

Is the GNU GPL “dying” or is that just the prejudice of those whose open source exploitation would be hampered by its use?                                                Italian version 

gpl-phobia_6243461518_o

At the huge FOSDEM developer meetup in Brussels in early February, I attended a panel where speakers discussed whether the use of “permissive” open source licenses like the Apache License is now outstripping use of “viral” licenses, such as the GPL. The discussion was spirited, with advocates associated with the Free Software Foundation pushing back on the assertion the GPL is “dying”.

Continue reading

Permissive and Copyleft Are Not Antonyms

Using the term “permissive” as an antonym to “copyleft” – or “restrictive” as its synonym – are unhelpful framing. Describe license reciprocity instead.

Assorted Empty Frames On A Wall

Some open source licenses implement a clever hack invented by Richard Stallman where, as a condition of the copyright license, anyone creating derived versions has to agree they will license the new version the same way as the original. In a play on words, this concept is called “copyleft” and many open source licenses implement this hack. Continue reading