GPLv3 Myth #5: GPLv3 is the best license for software
This article concludes a five part series on the latest version of the most commonly used software license: GPL. In this final part we ask the most important question of all: is GPLv3 the best license for software?
In case you missed it, here are the other 4 myths covered so far:
Disclaimer: This information was culled from a variety of sources, including the GPLv3 web site, interviews with experts involved in the process, and analysis from various industry watchers. However this isn’t intended as legal advice.
Myth 5: GPLv3 is the best license for software
There are two different categories of people who are considering adopting GPLv3 for their software:
- those with existing code licensed under GPLv2 or other licenses, and
- those writing new code trying to decide which license to use
Existing code
When you license code under GPL (any version), you can choose whether or not to automatically license it under future versions by including (or not) the phrase "or any later version" in the license.If you've already released code that includes this phrase, or code that does not specify a version number of the GPL,Quit giving Stallman a proxy vote in the software development boardroom then the decision is already made - your release is covered by GPLv3. That's why, before GPLv3 came out, there was a flurry of activity by projects to remove the phrase. They wanted to make sure they liked GPLv3 before committing to it.
In order to license code at all, or change an existing license, you have to hold the copyright to it or have permission from the copyright holders. That's why many major projects require copyright assignments or other contributor agreements. If there are dozens, or even hundreds, of copyright holders then that makes it much more difficult to execute a license change. So if you find yourself in this situation (diffuse copyright) then more likely than not you'll need to keep your existing license. If you hold the copyright or can get the holder's permissions, then it's very similar to having new code, so see the next section.
New code
Now let's take the common case where you're starting with a new project, or there is a clear copyright holder. The decision of whether or not to use GPLv3 comes down to one question: What's important to you? In other words, what is your #1 goal for allowing others to use your code?
Philosophy
When I talk to other developers about this, most of them fall into what I call the "pragmatic" category. GPL creator Richard Stallman hates this category, calling us "too lazy to resist" non-free software. Are pragmatic developers in favor of lower cost or no cost software? Sure, esp. when they're paying for it. Do we favor openness and standards? Sure, who can argue with that. Do we want to let end users modify their code? Well, maybe, as long as it doesn't mess anything up and they don't want us to support what they did.
By choosing to release your source code, clearly you want other people to use it. But do you want to divide those people into "a" and "b" groups, letting only the "a" people use it? How do you objectively distinguish between the two groups? Zero cost vs. commercial? Open vs. Proprietary? Modifiable vs. fixed?
If you choose GPL you're putting your eggs firmly in one basket. You're not just making a statement about your own wishes, but you're actively trying to sway people to your position. To get the full benefit of your code, other developers must share those same desires. If they don't, then you'll take your ball and go home.
Developers aren't that complicated
Most developers will tell you they don't care about the fine points and nuances of the different licenses. However we do care about having people recognize and appreciate our work, and we care about making the code better. To that end, various licenses have attempted to preserve credits in the software and make sure any improvements find their way back to the original developer so he or she can benefit from community efforts. GPL certainly tries to do that, but so do many other licenses.
I ask you: Do people need encouragement to do this? Should the license force "reciprocity" - the act of giving back any modifications and improvements? Apache doesn't think so, which is why you won't find that in their license (ASL). They believe that developers will just naturally come to the conclusion that sharing is good. Some obviously won't, but some will.
The un-level playing field
If GPL is anti-proprietary, does that mean GPL code cannot be buried deep in a proprietary program? Well, if you're an ordinary developer off the street then you're forbidden from creating proprietary derivative works. However, if you're the copyright holder, you can do whatever the heck you want.
Do you want to release a piece of code as GPL, benefit from community testing and improvements, and then make money from exclusively licensing that code (with some extra improvements of your own) in binary form only to paying customers? Sure. GPL allows this. ASL, for example, does not.
ASL and similar licenses level the playing field. Almost anything the copyright holder can do, regular people can do too. Embed it in a commercial product? Sure, go ahead. Keep any improvements to yourself? Ok, if you must. Of course if you make your own private changes, then it's going to be harder and harder for you to merge in any changes made by the community. So you may decide that it's in your interest to get your changes merged back into the "mainline version". But that's your choice to make as a down-level consumer of the code. The author didn't force that choice onto you.
Conclusion
Richard Stallman sums it up quite nicely. Do you:
(a) "support the values of freedom and social solidarity," or (b) "appreciate only powerful reliable software"
It's telling that he phrased this as an either-or decision. If you're 100% behind (a) then by all means go ahead and use GPLv3. But if you pick (b) or a mixture of the two, then you should really consider a different license, and quit giving people like RMS what amounts to a proxy vote in the software development boardroom.
It's unfortunate that such a simple concept (give people the source) has become so complex and tangled up in politics and social agendas. Maybe it's time somebody else took over the wheel and steered the ship back towards the mainstream of software development.