Previous: Using likely() and unlikely()
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:
- The vendor has to have a working business model independent on whether the software in question is made proprietary of free. For example, if you are building your proprietary commercial software using GCC, you can release your fixes to GCC as free software. The fact that GCC is free doesn't cause your commercial software to become free.
- The vendor has to have an incentive to publish the software in question. So, for example, if you are using the modified version of GCC in-house, you don't have to publish your changes. However, you may want to do so, to make GCC community maintain your code instead of you in the future ("throwing code over the wall").
- In general, to release you code under GPL license, the cost of re-writing existing GPL components from scratch must be greater than possible future profit from having a commercial, proprietary product.
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.
Martin Sústrik, Jun 27th, 2012
Previous: Using likely() and unlikely()
So how are going to resolve this license issue with Crossroads?
The code is licensed under LGPL which means that to change the licensing, all the past contributors would have to approve the license change. That simply won't happen.
This seems incompatible with the stated goals of Crossroads. In fact, it seems like it kinda kills the entire point of having created Crossroads, as you have described it above. The only way to move forward, if you don't find a way to solve the licensing problem, is to sit around waiting for someone else to reimplement it under the terms of a copyfree license.
Have you just given up on the stated goals for Crossroads, then?
I am working on reimplementing the library. It'll probably be MIT-licensed when it's ready.
That's excellent news. Let me know if there's something I (or others) can do to help.
Sure. I have to stabilise the basic architecture first, then I'll make it public. Any help would be appreciated then.
Hi,
There is an assumption that *other* people will help you with MIT licenced software.
I know of, and am one of, many people who refuse to contribute to non GPL software, precisely so that I never have to compete against some derivative of my contribution.
You keep making the case from a primary developer point of view, which is perfectly fine. The argument changes for contributors.
If you contribute something to a project, do you really want to see your competitor be able to take advantage of it? In most cases, no.
Which is why the GPL levels the playing field amongst competitive companies (e.g. Linux kernel done by Google, Oracle, IBM, Redhat, etc.).
The GPL is a good way to build a community (not the only way by any means) around competing developers. Which makes things better for everyone.
Are you really selling your GPL code so that if someone copies it he becomes a *real* competitor?
If not, you have no competitors and you are probably working for credit. And if so, other people using your code (even in a closed product) are source of the credit rather than a competition. For example, in job interview you can mention that your code is used inside Windows, iOS and Oracle DB. That would give you a lot of credit.
That being said I understand the position of considering the non-free software as evil and thus using GPL to hurt it. That's a perfectly consistent position to take.
BTW: If you are really selling your GPL code it would be interesting to discuss the motivation and the business model.
LOL, I'm opposite. I'll contribute most to free licenses such as MIT and sometimes LGPL. But GPL nope. I will rather find other project which is MIT than contribute to GPL. Only if there's no other choice, only them I'll help GPL
Martin, you don't seem to understand the requirements of LGPL. If you only use the code released under LGPL as a library, that is only statically or dynamically link to it, you can choose any licence you want for your final product (including proprietary one). Only the changes made to the library itself have to be released under LGPL.
That means that Windows, OS X, *BSD can use Crossroads/ZeroMQ no problem. But if they modify your code, the modifications has to be released as free software. But just the modification, not the rest of their code stack. Where is the problem then?
And one more comment about commercial potential of GPL (note, I'm not talking here about LGPL that was discussed above). You said that GPL projects charging money for distribution would be forked and distributed for free. But knowing that, why would you charge for making a copy? Charge for making the software instead, kickstarter-like. Then charge for customisation, new features, bug fixes, support, all the real work you do. Not for making a copy which costs you nothing :)
I've read both GPL and LGPL word-by-word. Several times.
Anyway, LGPL does make the situation better, but it goes just half the way. Imagine the hypothetical case that you want to re-use some of the ZeroMQ code in FreeBSD in-kernel implementation of a similar system. You just can't.
What about Linux in-kernel implementation? LGPL allows re-licensing the LGPL code under GPL, which is nice, however, it's not possible to re-license GPLv3 (ZeroMQ) as GPLv2 (Linux). So you are stuck once again.
Charging for making software: OK. How much are you willing to spend? :)
Seriously: The article takes a broader perspective. It doesn't say you can't make money on GPL software. That would be demonstrably untrue. What it says is that GPL in a non-trivial obstacle to the flow of money in the ecosystem. Which in turn means less developers, less man-hours spent of projects etc. and ultimately less free software.
The upside may be that unpaid work is usually better quality than paid work.
Btw, if I have some free time, I would like to write 2 more articles:
Interesting essay. The Github ecosystem appears to back up your observation on the advantages of MIT-licensed software (and other permissive licenses) in the free flow of money and ideas. As you are likely aware, the Github ecosystem, particularly when you don't count the software hosted there that was created prior to the advent of Github itself, is overwhemingly permissively-licensed. And it's clearly thriving.
I think the reason for this is a result of the obstacle you describe that GPL poses to the flow of money in an ecosystem. Some of the people who use the GPL like to think that they are somehow sticking it to the big companies by using the GPL. But it's not the big companies who are hurt by the GPL. They can easily pay for bespoke software, and they usually don't even care that the quality is sometimes inferior to open source software.
Small-time operations and freelancers, on the other hand — the small development firms, low-budget startups, and sole developers who make open source — are hugely hurt by the GPL. The above comment nonewithstanding, it's very hard to make money off of GPL software. Kickstarter has introduced a possible solution, but it's not clear that will work, and prior to that there was almost no solution for smaller operations except for the duplicitive and exploitative practice of "dual licensing".
Most young Github devs seem to have realized this, and are overwhelmingly licensing their software permissively. And so they all use each others software whenever they do need to create proprietary projects to pay the rent.
Which then allows them to then make more permissively-licensed open source, and so the cycle continues.
That's my thinking as well. One interesting additional thought would be that prevalence of GPL (I think it's still the leading OS license) have lead to expanse of software as a service as opposed to traditional packaged software. With SaaS you don't have to re-distribute your software even if you've used GPL'd components. That allows you to actually make money of it.
If the proposition is proved true, it would mean another unintended consequence of GPL, namely increased centralisation of the data, with privacy issues, spying and all the other stuff that ensues.
I think there is a hole in your argument.
Suppose I am a developer and I'm writing a library. I want to decide between licensing it as BSD or LGPL.
Suppose I make a living selling consulting related to this library - that is, developing proprietary software for clients that uses the library (which both the BSD and the LGPL allow). Sure, anyone else can offer the same consulting services, but I have a competitive advantage because I wrote the library (or most of it) and I know it the best.
Now suppose I licensed the library under BSD. Along comes Bob, and implements a new feature in the library. Had the library been LGPL, Bob would have had to release the new feature under LGPL, but this way he can keep it proprietary. He offers consulting services of his own, on top of the improved library. I now have to compete with his services, which may be more attractive to my clients because of the new feature - and yet, I did most of the work, I wrote all of the library except this feature.
You might argue that even if the library were LGPL, Bob would only have to give the source code of the new feature to his clients… but it would take just one client to distribute it to the public, and Bob's monopoly over it would be over - and clients, collectively, would have an incentive to do so, because having the new feature available to the public would reduce the value-added, and thus drive down the price, of Bob's services.
In theory, you are right. However, try imagining yourself in the customer's position.
You can choose between a fully open BSD-licensed product supported by the original developer and all the community around the project. Or you can choose Bob's proprietary closed source fork of the project that happens to have one additional feature.
Consider the consequences. To get one feature you are betting your business on Bob's ability to deliver. If Bob gets hit by a bus, you are in a trouble. Same if Bob decides to discontinue the product. Also, you are locked-in to Bob's product, thus at Bob's mercy. If Bob decides to double his rates, there's no one else to help you.
All in all, from a business perspective it makes more sense to hire someone (presumable the original developer!) to implement the feature you need and either merge it back to the project or keep the patch for yourself.
I am interested in your thoughts in relation to the various iterations of leadership, forking and progress outlined in the gpl'd WebKit Browser Engine, as described by John Resig, at
ejohn (dot) org/blog/webkit-is-the-jquery-of-browser-engines/
(posted February 13th, 2013). Basically, KDE creating ->KHTML, Apple -> WebKit, based upon that, Google -> WebKit/Chromium, and now with Opera participating.
Your point is well taken that you want NanoMSG to be incorporated as an infrastructure into all OSes, and the gpl impairs that aim.
For the browser, as "mostly" an application-level program, there does to appear to be a solid demonstration of how the forced sharing of gpl has allowed and furthered the improvement of browsers by multiple entities.
I would tend to agree, the WebKit history may or may not have much to do with your topic "furthering free software".
Well, I am not following the WebKit development, but my point was about GPL building artificial barriers. Thae this example:
"They can implement a number of their Opera-specific features into WebKit and it’s likely that those features will start to trickle back into other WebKit-using browsers as well."
If the case was that WebKit was originally BSD licensed, Opera took it and made it GPL licensed, the patches won't trickle back.
How can we contrast this with Android which is under APL(save the kernel), and getting fragmented by other vendors, ranging from Smasung to some small chinese manufacturer?
In this case, Google would had the benefit by licensing Android as GPL instead of APL.
One license does not fit all scenarios(OS , service software, libraries, etc), it actually depends on what your aim is and what strategy you would employ to forward it.
True, but this article wasn't making the argument that one license fits all goals. It makes the argument that for a specific set of goals, a license like MIT is better than GPL/LGPL.
As I see it, GPL in business requires the mental model that code is only written as needed (and that work is paid by somebody) and the resulting code is free (both as-in-beer and as-in-freedom). That is, GPL enforces that nobody can make money from the already created stuff and extra work is required in exchange for extra money. This directly goes against any business model that depends on "Copyright" as intellectual property or imaginary property that is rented, leased or sold. GPL cannot be enforced if "Copyright" does not exists at all, and in that case GPL would not be needed at all.
GPL is all about making sure that "Copyright" cannot be used to restrict the usage of a piece of work (both as-in-end-user-usage and as-in-used-for-derivative-works). MIT/BSD/Public domain is about making sure that end recipient of a piece of work is free to do whatever he pleases (roughly, credit must be preserved in case of MIT/BSD).
If you create a new piece of work, the work will receive most distribution if it's released under MIT/BSD/Public domain licensing because that allows most users (direct end users and creators of derivative works) to benefit from your work. GPL prevents creators of derivative works from getting more freedoms than the end users. As a result, you'll lose the part of the user base that is not willing to play on a level playing field.
The original motivations of the license for GNU's software were sound. Ultimately, however, the fanatical copyleft devolved quickly into feet stamping and spite.
I once even saw it claimed that if someone (A) releases code under a permissive license, and someone (B) forks it and releases their version under a proprietary license, that someone's (A) software becomes proprietary. There's not a whole lot of logic in statements like that.
All the above is true, but there's another aspect to it: The level part of the field is pretty small.
By using GPL you are locking yourself into a tiny corner of the ecosystem. Imagine how popular would Linux be if it required all the applications running on top of it to be GPL-licensed.
Yes, the original intention was that the leveled field will gradually expand until in the end everything is GPL. However, that doesn't seem to be the case. I bet it's for the same reason that real socialism haven't worked: Any system based on assumption that people would behave in such a way as to increase common good, even in spite of personal disadvantage, is not ecologically viable.
It's an unfair universe.
Your possition is a bit sad.
On the other hand you can stand the idea of the "unfair universe" only because you are not being able to think from the point of view of those hurt by that.
Lot of people will not be able to use MIT/BSD stuff, because it is only implemented in privative packages. Is this the time to think on those?
MIT/BSD license is conservative of the "status quo" you are only thinking from the point of view of someone on the winning side.
If it's private, it's proprietaty, not MIT/BSD, no?
http://www.softpanorama.org/People/Stallman/history_of_emacs_and_xemacs.shtml
The GPL license was created due to a fork of emacs which Richard Stallman was largely involved in at the time. A company was making money off of his work and being the irrational crazy individiual he is he over reacted and created an extremely restrictive license. His version of free I find is distorted and GPL to be quite restrictive. I am a commercial developer and only contribute to permissive licenses, as code snippets in any form can be useful to my fellow developers. Having a large base of reusable code helps everyone.
Is it necessary to code for money and fame? Although I do earn money from computer software, the idea of making money in paid-per-LOC sweatshops is alien to me and everybody I knew on my level of technical competence. If I do some serious coding, I do it mostly for myself.
MIT/Permissive - license of a professional coder, person who sees programming as a job
GPL - license of a computer literate person seeing software as shared utility. That person sees a point of maintaining software as a shared utility.
Over the years, GPL software became the de-facto only kind of software a regular person/amateur developer has a reasons to use. In a commercial setting, GPL made it so that companies that have access to a globally shared code base overtake those ones who keep writing their code from zero.
The reason for why there is no alternative for GPL's current and all future versions now is quite similar to why there can't be another Facebook.