1 2 next »

1. Decline of copyleft
2. Attribution and reputation

Why it's time to stop using open source licences

by Glyn Moody

Free software is built on a paradox. In order to give freedom to users, free software licences use something that takes away freedom – copyright, which is an intellectual monopoly based on limiting people's freedom to share, not enlarging it. That was a brilliant hack when Richard Stallman first came up with it in 1985, with the GNU Emacs General Public Licence, but maybe now it's time to move on.

There are signs of that happening already. Eighteen months ago, people started noting the decline of copyleft licences in favour of more "permissive" ones like Apache and BSD. More recently, the rise of GitHub has attracted attention, and the fact that increasingly people have stopped specifying licences there (which is somewhat problematic).

I don't think this declining use of copyleft licences is a sign of failure – on the contrary. As I wrote in my previous column, free software has essentially won, taking over most key computing sectors. Similarly, the move to "permissive" licences has only been possible because of the success of copyleft: the ideas behind collaborative creation and contributing back to a project are now so pervasive that we don't require "strong" copyleft licences to enforce them – it's part of coders' mental DNA. As Ian Skerrett put it in 2011:

Developers or companies don’t need to be kept honest; developers and companies contribute in open source projects because it helps themselves. If developers needed to be kept honest, why are there so many successful Apache projects today? Looking at Eclipse projects, which uses a weak copyleft, I know of very very few contributions that have come into Eclipse because the developer was ‘forced’ to contribute due to license obligations. People contribute back once they have used the project technology and see benefit to themselves for contributing back.

That's also why we don't need to worry about cloud computing – sometimes presented as a deadly threat to traditional copyleft licences – since there is no distribution that triggers compulsory contribution of code changes. But once more, we don't need that compulsion: if a cloud computing company wants to get the full benefit of free software, it will contribute back anyway. If it doesn't, it's missing the point.

So what licence should we adopt if not one using copyleft? Apache? BSD? How about no licence at all – that is, putting software into the public domain? After all, that's the logical conclusion of the move to more "permissive" licences – one that permits everything.

Given the heated discussions that tend to occur over the suggestion that there is a move from traditional copyleft licences to even mildly permissive ones, I suspect the idea of moving all the way to a licence that is totally permissive will be shocking to some. It may even appear self-evidently impossible, since it would "clearly" lead to the collapse of free software itself if widely adopted.

A fascinating paper by Clark Asay, Assistant Professor at Penn State University Dickinson School of Law (and also the brother of the well-known open source figure Matt Asay) explores this idea in depth, and offers some convincing arguments why putting free software into the public domain would work, and offers benefits.

Asay (Clark, not Matt) notes that there is a cost to using free software licences in terms of compliance. Companies have to spend a lot of money worrying about doing the right thing, but programmers, too, waste time dealing with legal details when they could be writing more lines of code. In particular, incompatibility between the many licences and variants is a major barrier to wider re-use and collaboration. Those issues mean that free software is not being used as widely and efficiently as it could, both commercially and non-commercially. That friction may explain in part the move to more "permissive" licences, driven by a desire to avoid precisely those problems.

Asay then goes on to examine the two key objections to making code freely available without any kind of licence. One is the fact that companies may take the code and enclose it, which he notes is unlikely to happen because doing so negates many of the unique benefits of free software:

if a firm were to take and close a project, they almost certainly would not obtain the free labor that contributors around the world are willing to provide to open-licensed projects. Without that free labor, firms would lose the most significant advantages of an open model of innovation, and the free labor would likely remain loyal to the open version of the project. Firms thus already have incentives to open and contribute as much of their materials as possible, since doing so will attract free labor and trigger innovation in directions that better suit the firm and its strategic direction.

Does reciprocity [the requirement to contribute changes back to the project] prevent defections from individual contributors? It seems unlikely that individual contributors in most cases have the time, interest, or resources to take from a non-reciprocal project and use it as the basis for a closed one. The literature suggests that the purposes of individuals in contributing to open-licensed projects have little to do with direct economic advantage; rather, their interests in contributing primarily lie in creativity, reputation-enhancement, and indirect economic rewards. While it does remain a possibility that individual contributors may take and close an open-licensed project as part of their own product or service, and thus technically defect from an open model of innovation, the same reasons that suggest firms are unlikely to do so suggest individual contributors are unlikely to do so as well. Individual contributors may be even less likely to defect given their purposes in being involved in open-licensed projects in the first place, as well as their much more limited resources to successfully close and then maintain a project.

The other key objection he tackles is that if software is placed in the public domain, there is no requirement that coders should receive the recognition that they deserve for contributing to a project. That recognition may be important because of the peer esteem they enjoy as a result, and it may even lead to economic rewards in the form of job offers and an enhanced salary.

Next: Attribution and reputation

1 2 next »