Occupy GPL the movement to rid the world of non-permissive open source licenses
occupygpl.org
occupygpl.org
If, on the other hand, you release under the MIT license and discover after a few months that your "community" is a bunch of product companies using your code without contributing anything back, you cannot easily GPL your code. Everything you released under the maximally permissive license will stay released that way.
Think also of the dynamics of forks. If you look at GPL->MIT and MIT->GPL as two instances of a fork, it's easy to see why GPL->MIT leaves you with the winning fork: people will probably gravitate towards the more permissive fork. On the other hand, if you fork and GPL, your competitors will have a lot of incentive to make sure that the MIT fork wins.
People have a habit of looking at the GPL solely through the lens of politics and principles. But the GPL is also a very valuable business tool. It allows companies to open-source things that they wouldn't otherwise be willing to open.
Overall, it would be a great thing if all code were AGPL and everyone had to simply work out reasonable livelihoods and business arrangements within that neutral commons framework. The issue is that a world of mixed proprietary and open code is an uneven one with tragedies of the commons. Copyleft helps avoid those tragedies, which every player actually wants to avoid.
For example, Objective C wouldn't be supported by GCC unless Steve Jobs hadn't been forced to license the Objective C frontend under the GPL. c.f. Apple not making the source to the Swift compiler available, since LLVM is more permissively licensed. Now it is very difficult for people to create extensions, or submit bug fixes etc to Swift.
There's a case of a Lisp compiler being made open source simply because the developer wanted to use readline.
Licensing your software under the GPL can precipitate more software being licensed under the GPL. It leads to improvements and bugfixes being made public, and ensures that the developer can receive something back from those who use the software.
On the other hand, it's clearly not for everyone. If you as a developer wish to see your code being used on as many computers as possible, then you'll be cutting off some of your potential market by licensing your non-standalone tool as GPL.
The odd thing is that this site seems to suggest a false dichotomy of GPL vs permissive. It's perfectly possible to (say) dual license software as GPL or commercial - any company that sees value from your software could have the choice of paying $100 for a license.
If your software holds enough value to them that it saves them a day or two of their developer time, then everyone comes out on top.
"the company needs to ship a product so it’d like to keep their core closed source. The GPL outlaws this kind of interaction. Our good citizen, a company wants to release their patches to your library back to the community and yet the GPL is banning them from doing so!"
That last sentence is utterly false, and the exclamation point doesn't make it true. The GPL is absolutely not prohibiting them from distributing their patched version of anyone's library. It merely requires that if they do so then they might have to publish other source as well. MIGHT. I'll get to that in a moment. The point is that GPL is adding a requirement, not a prohibition. Might they find that requirement onerous? Certainly. Nothing wrong with that, but portraying it as a prohibition is dishonest.
Now, about that "might" part. GPL might require that you publish other code only if it meets operative definitions of linkage and derivative works. Those are complex issues which I doubt can be addressed adequately here on HN, but maybe we can set some bounds. At one extreme, if you use a public API to an existing library which is loaded separately from your proprietary code, you're almost certainly OK. At the other extreme, if your proprietary code meddles in the GPL code's internals or vice versa (via your patches) to the extent that either becomes meaningless without the other, then you'd probably be held to have created a derivative work and would be required to publish the interdependent code under GPL.
The way this works out in practice is that the majority of proprietary/GPL combinations actually do not create an obligation to publish anything except your patches to the GPL code involved. When that's not the case, it's by design to prevent the "secret sauce" version of a library from displacing its still-open antecedent. Agree, disagree, but please don't misrepresent.
sigh
Then why have a license at all?
You have to draw the line somewhere - we live in a complicated world full of complicated humans. The FSF chose to draw the line in a very particular way and they have perfectly good reasons for doing that. Other people or companies choose differently for different reasons[0]. This site tries to even landgrab the very particular phrasing of "Free" that the FSF uses. The guts of some people.
[0] The site mentions MIT, BSD or zlib as licenses but guess why Google chooses Apache? Because patents. Because the world is a complicated place full of complicated people.
For my open source libraries, I use the Unlicense, because I want to minimize licensing friction. But if I'm distributing (say) a complete end-user application that represents programmer-years of work, I'm likely to use the GPL, because I may not want somebody to fork it and make it proprietary. It's my code and my decision.
If you want to use my GPLed code in your proprietary product, you can find my email address and pay my company an appropriate license fee. And if you think this is somehow unfair, my wisest course of action is probably to avoid doing any business with you: You're raising all kinds of "horrible customer" warning flags.
My point is -- Unlicense doesn't do too much to minimize license friction and actually creates complicated international issues. I don't use it -- because I don't want to have to hand out "special" licenses based on where my users live.
And, no, losing ability to impose your power over others via a proprietary license isn't a reduction in your freedom. GPL is not non-free, it's non-power-enabling. GPL says you can do as you like but not restrict the freedom of others. To be absurd, "the freedom to own slaves" is not freedom, and analogously, "the freedom to restrict others via proprietary licenses" is not freedom.
Ultimately, different licenses work well for different projects. More permissive OSS licenses (BSD/MIT and other) seem to be the best choice for libraries and other bits of code that can be freely shared and used without worrying about modification restrictions, linking, etc etc.
GPL on the other hand has really found its niche in larger projects for complete software packages that often are primarily developed by a single entity but made open to allow contributions and customizations.
Both types fit a use case, both types are useful and we have seen success using both models. Why isn't that good enough?
Sure, you could update the library you use and release those changes as open source while you make closed source software. But people pay you for your software, why shouldn't you pay for the libraries you use?
GPL is a free license.
That's just completely false. It does not restrict who can use it. It restricts how you can use it, but not who can use it.
I think it would be better to catalog the licenses into categorical types so that we could then more intelligently decide which license to use, and also understand our own "chosen" licenses better.
In some cases, the GPL may be desired or even necessary to achieve the vision/goals of the authors of some software.