As the best-known free software and open source license, the GNU General Public License, or GPL, has become both a rallying point for the free software and open source (FLOSS) communities and a focus of FUD (Fear, Uncertainty and Doubt) campaigns for those who fear that these movements will destroy their revenue streams.
Let's take a look at some of the issues and misunderstandings that get in the way.
Let's hit the easy stuff first. The GPL in no way prevents you from selling your software.
It also doesn't mean you have to give the source to anyone that asks, even people who aren't your customers and the GPL does not cover the program's output. If you want to license the output of something you can do so however you like -- as long as part of the program's source isn't part of the output.
The GPL does state that if you sell your software to someone in binary form and they ask for the source, you have to give it to them for the reasonable cost of the materials (say, a CD) and shipping. Or, you can't charge a fee for downloading the source that's higher than you charged for downloading the binary.
Also, if you modify a GPL'd program for your own purposes in-house, you do not have to release that modification. However, if you distribute your changes, then you also have to make the modified source available.
The GPL and Versions
One clause you'll find in the license declarations from many popular open source Content Management Systems is the statement that the software is licensed under "GPLv2 or any later version of the GPL."
If you've never encountered this statement before, it can be jarring. Yet, this is the recommended approach from the Software Freedom Law Center, the entity that advises many of the major FLOSS CMS projects -- Drupal and Joomla! for example.
According to footnote 9 in "A Practical Guide to GPL Compliance":
However, most so-called GPLv2 programs are actually distributed with permission to redistribute under GPLv2 or any later version of the GPL (“GPLv2-or-later”). In the latter cases, the redistributor can choose to redistribute under GPLv2, GPLv3, GPLv2-or-later or even GPLv3-or-later. Where the redistributor has chosen v2 explicitly, the v2 termination provision will always apply. If the redistributor has chosen v3, the v3 termination provision will always apply. If the redistributor has chosen GPLv2-or-later, then the redistributor may want to narrow to GPLv3-only upon violation, to take advantage of the termination provisions in v3.
Making Complicated More Complex?
Does using such language ultimately complicate already complex legal issues? Neither the Free Software Foundation nor the Software Freedom Law Center seem to think so.
According to Pamela Jones of Groklaw, this phrasing is designed to legally and administratively simplify things for FLOSS projects. "It also makes enforcement by FSF faster and quicker, for those parts of code that are given over to FSF to protect."
GPLv2 and GPLv3 Incompatibilities
Another issue the phrasing simplifies is the fact that the GPLv2 and GPLv3 are in some cases not compatible with one another. If you have a project that needs to use some code licensed under GPLv2 and some code licensed under GPLv3, adopting the "or later" language can help ensure license compatibility.
Joe Brockmeier, openSUSE Community Manager, says that he feels that the suggestion to use "or later" is a way of pushing people to adopt the most recent version of the GPL, version 3, which has not been adopted as broadly as version 2. Brockmeier says he prefers "specificity," as far as linking to the specific version of the license that's in use.
Jones points out that the GPLv2 or later language was in use long before GPLv3 was written. The GPLv2 was published in 1991 and it included this language:
Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.
The GPL and Content Management System Extensions
One of the biggest issues around the GPL in the Content Management Systems community is around modules, extensions, add-ons or whatever you want to call the external pieces that third parties might build to extend a particular CMS's capabilities.
Generalizations are Elusive
This topic is so thorny to discuss because the intersection of license and copyright issues for code extensions makes it nearly impossible for a lawyer to make general statements on the matter.
Some take the very strict interpretation that all extensions to a GPL project should also be licensed by the GPL. In some cases, this decision may simply be to avoid complex legal wrangling over the subtleties inherent in each individual case. Even commercial companies couldn't afford much of this, let alone open source projects run by volunteers.
Focus on the Interface
In general, if you at all have to modify the project's source to install your extension, then your code is bound by the same license as the source code. Code that goes only through the API on the other hand may not be strictly considered a derivative work.
When trying to understand this issue, Russ Nelson, an open source developer, offered that if the only interaction is at the level of a public API, the project's software could actually be replaced with other software that also used that API. So, the extension could in fact be used without needing the project's code.
CMS Projects Handle this Differently
You can see how the different interpretations of this issue play out within the various open source CMS projects.
Joomla! has decided that all extensions listed in its own resources will have to be licensed with the GPL. Drupal is the same. Plone is discussing allowing exceptions on a case by case basis and even then will specify which alternative license can be used for those exceptions they approve.
Who Has Got it Right?
Ultimately, there's no way to say with certainty who is right unless a dispute makes it to court -- though some follow a policy of deferring to the license creators when unsure.
Lawyers can speak as long as they like, but it's the courts that make the final call. No project, company or individual so far has been wiling to risk those muddy waters, but everyone is doing their best to make what they feel is the right decision for their community.
Do keep in mind that when you contribute code to a project, you contribute that code under a specific license version. You will not be held to any obligations created by later versions of the license even if the project itself uses the "or later" language.
The GPL and CMS Templates
Templates are a simpler issue. Kind of.
The Free Software Foundation's GPL FAQ explicitly recommends releasing templates under a simple permissive license to keep things uncomplicated.
Within the FAQ, you will find a GPL exception for such code. Read and apply it carefully.
The third major issue is that of what is compatible with the GPL (though this issue of course occurs with any license).
When it comes to using source that is GPL'd in the same code as source from under another license, the big question is whether or not the two licenses have conflicting permissions or obligations.
To go to an extreme, if one license demands that you give the source to anyone that asks and another demands that you not show the source to anyone who hasn't paid the original developer, these two licenses are considered incompatible. Depending on the licenses, you may be able to use both pieces of code by linking them as separate libraries or through another method.
Some GNU Licenses Don't Get Along
Interestingly, not even all GNU licenses are compatible with one another. In the Frequently Asked Questions about the GNU Licenses document, you'll find a compatibility chart telling you which GNU licenses can be used together and which can't.
The GPL and Patents
When it comes to patents, it's hard to talk too much about this issue, as everyone asked ran screaming from discussing it.
Some licenses explicitly address patents. Others address them only in an implied form, while still more say nothing at all about the issue. See the FSF FAQ for more information when it comes to the Free Software Foundation's licenses.
The GPLv3 does explicitly address patents in section 11. In its preamble, the license states:
Finally, every program is threatened constantly by software patents. States should not allow patents to restrict development and use of software on general-purpose computers, but in those that do, we wish to avoid the special danger that patents applied to a free program could make it effectively proprietary. To prevent this, the GPL assures that patents cannot be used to render the program non-free.
There is no license out there that can completely protect you from patent issues, since only the people using a license are bound by it. Until the US software patent system is fixed, patents will continue to cast a shadow over all software development.
Too Much Trouble?
Before you start to say that FLOSS licensing is too much trouble, have you read a closed source software license recently?
Remember that the purpose of this community's software licenses is for programmers to ensure that the code they may be giving away for free continues to be used in a way they find acceptable.
Given the billions of dollars worth of programming effort the FLOSS communities have provided, that's not a lot to ask in return. Just make sure that if you're a programmer wanting to use code licensed with the GPL or any license for that matter, you take the time to read the license you're dealing with and understand its terms.
For a more in-depth education on a variety of FLOSS licenses, check out Black Duck Software's ongoing series of legal seminars on open source licensing.