I've run into a problem recently.
As explained elsewhere, my long-term goal was to use Crossroads/ZeroMQ as a first step on the road to messaging as native layer of the Internet stack. The idea is that in addition to routing layer like IP and reliability layer like TCP there should be a scalability layer, similar to Crossroads/ZeroMQ available out of the box, as part of operating system, everywhere and without a need to care about it. That, obviously, means that the scalability layer should be part of different operating systems: Linux, Windows, different BSD flavours, OSX.
Now, Crossroads/ZeroMQ is licensed under LGPL. That's fine for re-using [parts of] the code in Linux kernel implementation of scalability layer. However, what about proprietary systems like Windows? And what about BSD-licensed operating systems? LGPL effectively prevents the code re-use in these cases.
My original conclusion was that there are two different notions of "free". (Forget about free-as-in-speech and free-as-in-beer for now.) First, there's "free" software as defined by FSF: software that's free to be run, to be studied, distributed and modified. And then there's "free" as it is often used when referring to the Internet: fully distributed, ubiquitous, based on open standards, with no central point of control. So, if your goal is to promote the "freedom" in the former sense you choose GPL. If you aim for the latter you'll go with MIT or BSD or simply leave the code in the public domain.
I've settled for a while with this analysis. However, at the same time I've started wondering about how is GPL supposed to promote the former sense of freedom. How does it encourage creation of software that people are free to run, study, distribute and modify?
Everybody agrees that the four freedoms are great thing and having a lot of software that grants them is even better. However, these freedoms are provided by a large range of licenses. There's nothing GPL-specific about them. So how exactly is GPL supposed to incentivise programmers to write code that offers those freedoms? What are the social dynamics implied by the GPL that would eventually make people write free software?
Consider my case: If GPL is preventing me to make it part of BSD kernel it's actually diminishing the amount of code granting four essential freedoms. Which contradicts the very goal of GPL license. So, once again, how is GPL supposed to promote creation of free software?
What are the possible scenarios? Maybe the idea is that GPL is designed to make users free, thus the users will vote with their feet and demand GPL licensed software. The vendors would meet the demand by producing more GPL'd software and that way deliver four freedoms to the whole community.
Well, that's definitely not the case. Users do demand four freedoms. They don't demand GPL though. Actually, the GPL is often seen as a stumbling block as it requires user's own product to be GPL licensed as well. MIT or BSD licenses fare much better in this respect because they allows users to create both free and proprietary software.
Let's try a different explanation. For example: "Free as in speech" doesn't necessarily imply "free as in beer". The makers of GPL licensed software should sell it in the standard commercial way.
Unfortunately, that doesn't seem to work. Any project with substantial value would be quickly forked and distributed for free which would in turn ruin the original developer's business model.
The idea to provide the product for free and charge for additional services seem more viable. Let's consider the case of individual developer who makes a living from offering consultancy for a product he made. As far as he is concerned, licensing the software under GPL severely shrinks the potential user base. No producers of commercial software are going to use the product and — alas! — those are exactly the guys with money. The GPL license decreases the overall revenue, maybe even the chance to survive in the market.
But wait a second! GPL prevents other companies and developers to take the software and sell it for themselves, right? That's a strong incentive to create GPL'd software, right?
Well, no. Actually, it's irrelevant. It prevents selling the software as such, but it doesn't prevent anyone to sell the consultancy. In that scenario GPL — as opposed to MIT or similar licenses — only shrinks the target market but doesn't change the balance of powers between the original developer and the potential copycats.
The only way for the original developer to gain business advantage is to use dual licensing model. The software is free to be used in other GPL licensed software, however, to use it in proprietary applications you have to buy a license from the original developer. This model actually works — just check the story of MySQL. It has two fundamental problems though.
First, the product can't use any other GPL licensed software. The original developer has to own all copyrights to be able to offer an alternative commercial license. That strips the developer of the primary advantage that free software is supposed to provide: the networking effect, the fact that you can re-use the code and build new products using components that were already designed, written and tested by others. Thus, the developer wastes his efforts on rewriting existing pieces of code rather than producing new valuable free software.
Second, dual-licensing, when used as a tool to take advantage of the work done by volunteers and sell it for money, directing the revenue only to the original developer, is generally seen as unfair. It makes developers shun the dual-licensed projects which makes the amount of free software smaller in the long run.
There is still an option to package the GPL licensed software and sell enterprise support for it. This is what Red Hat have done after all and it's a billion dollar company today. There are two reasons why this model works. First, there's an exception from GPL for the applications built on top of Linux kernel. The applications running on Linux can be proprietary.
Second, enterprises often create software for their own use. According to the GPL license they don't have to distribute their code unless they provide it to a third party. In other words, if they deliver binaries to a client, they have to attach the source code. If they don't deliver anything, as is the case of most software in banking industry etc. they don't have to make their code public.
Note that in both cases the free software benefits exactly as much as it would if the code was in the public domain. In the former case, there's a proprietary product running on top of free Linux kernel. In the latter case there's no publicly available product at all.
We can argue that although Red Hat clients don't produce any free software of their own, they pay for licenses and Red Hat uses part of its revenue to develop more free software. Yes, that's true. However, it would hold true even if the software was MIT licensed, BSD licensed or even part of public domain. There's no specific advantage resulting from GPL here.
Now, let's assume GPL is not aimed at software produced in commercial environment and its goal is rather to promote creation of free software by hobbyist programmers, in academia etc. What's interesting in this scenario is that money are no longer part of the equation. They get replaced by credit. Hobbyist programmers are rewarded by the fame they gain in the community. That being the case, permissive licenses make more sense in this case given that by using GPL you limit the community that will use the software and give you credit for it. For example, you may feel good if your code is made part of a BSD kernel. If you choose the GPL license, that door is closed for you. Even having one's code in a closed proprietary product can be source of credit: His code runs inside every iPhone and iPad. Cool!
Yet one more case: You may be natural born altruist and you may want to give your software for free, not caring about money or credit. In such case permissive licenses or public domain seem to match your needs more than GPL.
Finally, adoption of GPL may be driven by spite: "I won't let those damned multi-national corporations use my software!" Which makes a lot of sense, especially if the programmer is a young, idealistic and doesn't have to care about making money for living. In the long run, however, spite probably won't work as well as positive incentives such as money and/or fame.
Having considered the options above, let's look at the argument for GPL provided by FSF itself:
That's an interesting argument. However, it based on the false assumption that you — as a developer — are selling the free software you have developed. Actually, aside of dual-licensed projects, I am not aware of a single case where free software is sold in such a straightforward way. More often, people are providing consultancy services around free software, in which case a company using the software to provide an improved proprietary version is seen as consultancy opportunity rather than competition.
On the other hand, if the "competition" is meant in terms of credit rather than money, proprietary product is severely disadvantaged by the very fact that it's proprietary. Only those who pay for it have access to it, so the fame you can gain through it is rather limited. It's reasonable not to even think of proprietary products as competitors for fame.
More nuanced argument for GPL is given in Richard Stallman's essay "Copyleft: Pragmatic Idealism". Please, read the essay to get more balanced view.
The argument of the essay is that in some cases copyleft, i. e. GPL, have caused people to write free software rather than proprietary software. As far as I can see, the preconditions for this scenario are:
As far as I can say these circumstances are pretty rare and limited only to a subset of software (certain kind of infrastructure components).
On the other hand, GPL creates an artificial barrier between the GPL licensed software on one side and proprietary, public domain and permissive-licensed software on the other side. The network effects, which are the true productivity multiplier in the software world are not able to bridge the barrier.
First, usage of GPL licensed software in commercial products is very limited (it's only done by exploiting the loopholes in GPL), thus, the flow of money and resources from commercial establishments to free software community is very limited at best and non-existent at worst. Developers are forced to do other work for money and write free software in their spare time. As a consequence, much less free software is produced.
Second, GPL licensed software cannot be used to create public domain, MIT or BSD licensed software. Thus, the developers are forced to waste their time by re-implementing what already exists in GPL domain and the result, once again, is less free software available for everyone.
All in all, it seems that while GPL encourages creation of free software in some limited circumstances, it hinders the development of free software in more common cases.
As a conclusion I should say that I've deliberately started with the false assumption that the goal of GPL is to maximise the amount of free (as defined by FSF) software. That assumption is obviously not true. The real goal of GPL is to eliminate non-free software and thus prevent its negative consequences such as software spying on users, extortion by vendors (lock-in), captive data, monopolisation of whole areas of functionality etc.
There was a saying back in cold war times: "Where the fat one gets slim, the slim one dies." The idea was that by escalating the arms race you can economically ruin your adversary. Similarly, the goal of GPL is to hurt proprietary software more then it hurts free software. By adopting GPL you are trading less free software for even less proprietary software. And, as always, this trade-off is yours to make.
Jun 27th, 2012