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

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

Reciprocal vs Non-reciprocal

I’m not keen on much of the language they were using to describe licenses, like “permissive” and “viral” to describe the Apache License and the GPL respectively. The GPL is a fine open source license that grants all the permissions needed by developer communities that adopt it. There is no sense in which it is not “permissive”, so to use that term as an antonym to “copyleft” verges on abuse. I prefer to consider the degree to which open source licenses anticipate reciprocal behaviour.

The Apache License grants all its permissions without any expectation that those passing on the software to others will also pass on the same freedoms they enjoy. Copyleft licenses anticipate that developers will share the freedoms they enjoy as well as sharing the source code. So I term licenses like the Apache License “non-reciprocal” and those like the GPL “reciprocal”.

There are many licenses in each of those two categories, with a wide variety of other attributes as well. For example, the BSD and MIT licenses are also non-reciprocal while the Eclipse License and Mozilla Public License are also reciprocal. There are also attributes other than reciprocity by which licenses might be classified, such as the nature of required attribution.

You can prove anything with statistics

One reason for the dispute is that there’s a fairly clear commercial motivation behind the statistics that are being used to support deprecation of the GPL. They come from companies that sell assurance and analysis services for open source, and who promote “license compliance” as a risk for developers. They have a vested interest in developers fearing reciprocal licensing because they aim to monetise the amelioration of that fear. Look at pretty much any scare story about “license compliance” and it will somehow be connected with what one speaker called the “compliance-industrial complex” and the companies behind it.

The complexity arises from the subjectivity of phrases like “a decline in the GPL”. Even when linked to data apparently supporting the statement, underneath is an assumption that the “popularity” of a license is demonstrated by the metric being cited, such as the number of new projects on Github using non-reciprocal licenses. Anti-GPL articles almost never justify why their popularity metric is valid. If I can pick my own metric, I can prove anything! Surely the number of users using the software is the best metric? Or the number of lines of code under the license? Or the number of committers collectively working on projects under that license? Or the number of published articles advocating for it? Or the total revenue dependent on its existence?

Certainty & Safe Spaces

So what is really going on? An open source project is the “safe space” in which developers with an interest in a piece of software, for whatever reason, are able to collaborate over its evolution without the motivations of others impacting their own usage. The open source license the project uses defines and guarantees the things over which those developers need certainty. All give the right to use the code for any purpose, to share it with anyone, and to make whatever changes they want. Beyond those essential freedoms, different communities need different certainties. As Eben Moglen likes to say, “licenses are the constitutions of communities”.

Communities working on code that is normally used directly, alone and in its entirety – application software such as LibreOffice, for example – may well want their license to also guarantee reciprocal grants of the same rights to other developers. Most of the LibreOffice core developers work for companies that offer support, training, customisation and deployment. Because everyone who offers these services has to contribute their work as a license requirement, it’s much less likely that a freeloader will be able to undermine their business. The reciprocal license – in this case the Mozilla Public License v2 – is a key attribute expected by the community. Other projects such as GNOME and the Linux kernel use reciprocal licenses (the GPL in those cases) for similar reasons.

This is not true of every community though. For developers mixing ingredients from multiple origins – frameworks, components, libraries – reciprocal license requirements increase the uncertainty rather than decrease it. Their employer may be concerned about managing the different reciprocal duties of different licenses, such as the Eclipse Public License (EPL) and the CDDL. The different expectations of the nature and rigour of proof of reciprocity by different communities may also be a concern. For these developers, it is much simpler to use a non-reciprocal license like the Apache License for their work, especially if the code in question is not directly monetised.

Horses For Courses

Neither of these approaches are the One True Way. Both have their place, and both have substantial, growing international acceptance. All the same, the growing acceptance of open source for corporate use – some would now say “dominance” – could easily appear as the most important trend to those whose gaze is fixed in that direction. There is no doubt that the growth of corporate open source development has seen new code aimed towards it tend to use non-reciprocal licenses.

So perhaps the best way to view the subject is to note that the open source world has grown enormously. The use and support of the GPL has grown with it, but new strengths have also emerged related to corporate adoption of open source, leading to stronger growth of associated approaches to licensing.

Deciding which is dominant may well be a matter for your ideological biases rather than an objective absolute. But we can all agree that software freedom is now the core principle for the world’s software.

• (A derivative of this article appeared in the Linux Voice section of issue 197 of Linux Magazine, April 2017)
• (This article has been translated into Italian)